www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Exceptions

reply nick <nick.atamas gmail.com> writes:
Keeping it brief:

Shouldn't exception catching be mandatory as in Java?

If not, then shouldn't functions/methods still have a throws keyword so 
coders know what to catch?

Sorry if this has already been discussed.
Jan 25 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
nick wrote:
 Keeping it brief:
 
 Shouldn't exception catching be mandatory as in Java?

Why? Exceptions should be allowed to pass as far up the call stack as the programmer wishes them to.
 If not, then shouldn't functions/methods still have a throws keyword so 
 coders know what to catch?

Coming from a C++ background, I have a personal bias against throw specs, and I think some of the same reasons can be applied to D. Throw specs are really only useful if every function provides one, and D's near seamless integration with C library code makes this impossible. For example, say I do something crazy like this: void fn() { throw new Exception("Surprise!"); } extern (C) void callFunction( void(*)() ); callFunction( &fn ); The C function cannot have a throw spec and yet I've just created a situation where an exception will be thrown from it. And contrived situations aside, hardware errors can also cause exceptions to be thrown, which can obviously occur in functions with no throw spec. Also, from an implementation perspective, I think a throw spec might have to be mangled into the function name, and this isn't possible for functions with C linkage. In C++, about the only use for throw specs is to provide the strong exception guarantee (that the function will not throw under any circumstances), and even this finds little use outside of dtor calls. And since throwing an exception out of a dtor does not risk a call to terminate (because the exception will override the one that is already in flight), there is no need for such a guarantee in D. Sean
Jan 26 2006
next sibling parent reply nick <nick.atamas gmail.com> writes:
On 2006-01-26 00:06:24 -0800, Sean Kelly <sean f4.ca> said:

 nick wrote:
 Keeping it brief:
 
 Shouldn't exception catching be mandatory as in Java?

Why? Exceptions should be allowed to pass as far up the call stack as the programmer wishes them to.

void A() throws Exception {throw Exception("hi");} void B(){A();} // This doesn't work void B() throws Excpetion {A();} // This works So the exception can pass up the call stack, but now the programmer is explicitly aware of what is going on.
 
 If not, then shouldn't functions/methods still have a throws keyword so 
 coders know what to catch?

Coming from a C++ background, I have a personal bias against throw specs, and I think some of the same reasons can be applied to D. Throw specs are really only useful if every function provides one, and D's near seamless integration with C library code makes this impossible. [...SNIP...]

what errors could occur. That way, one doesn't have to look through docs to find a list of exceptions that could be thrown. Having written a fair share of Java code, I find enforced exception specs fantastically useful. Of course, there would be 2 types of excpetions: (1)normal and (2)runtime. 1)Normal exceptions must either be caught or explicitly propagated as in the example above. 2)Runtime exceptions are exactly l ike C++ exceptions. I don't think that D users should be deprived of such a valuable high-level tool as handled exceptions.
Jan 26 2006
next sibling parent reply xs0 <xs0 xs0.com> writes:
nick wrote:

 Having written a fair share of Java code, I find enforced exception 
 specs fantastically useful.
 
 Of course, there would be 2 types of excpetions: (1)normal and (2)runtime.
 1)Normal exceptions must either be caught or explicitly propagated as in 
 the example above.
 2)Runtime exceptions are exactly l ike C++ exceptions.
 
 I don't think that D users should be deprived of such a valuable 
 high-level tool as handled exceptions.

Well, having written a fair share of Java code myself, I tend to disagree. First, the normal/runtime distinction is somewhat arbitrary, even in the Java libraries itself. For example,
 Integer.parseInt(input_from_user)

will fail often, yet throws a "runtime" exception, and you must specifically remember to wrap it in try/catch. On the other hand,
 some_string.getBytes("UTF-8")

will never fail (Java standard mandates support for UTF-8), yet declares a non-runtime exception, so must always be wrapped in try/catch, resulting in unnecessarily ugly code. Second, with code of any significant complexity, you soon need to either declare like 19 specific exceptions, or just wrap them into "throws Exception", which is what most people seem to do (at least where I work), at which point the declaration is totally useless, as you can basically get an Exception from any code anyway.. Third, declared exceptions really fail to work with interfaces well. For example, suppose you have something that can work either with RAM (and can fail with OutOfMemoryError), with a file (IOException) or with a database (SQLException). A common interface will either have "throws Throwable" (totally zero information again), "throws Exception" (almost zero information, and you'll probably forget about OutOfMemory), or nothing, forcing you to wrap those IO/SQLExceptions into RuntimeExceptions, and you'll need to read the docs anyway :) xs0
Jan 26 2006
parent reply Mike Parker <aldacron71 yahoo.com> writes:
xs0 wrote:


 specifically remember to wrap it in try/catch. On the other hand,
 
  > some_string.getBytes("UTF-8")
 
 will never fail (Java standard mandates support for UTF-8), yet declares 
 a non-runtime exception, so must always be wrapped in try/catch, 
 resulting in unnecessarily ugly code.

"UTF-8" is just one of many possible arguments to this method, so throwing a checked Exception makes sense. Throwing a runtime exception just because one potential argument will never throw wouldn't be a good thing.
 
 Second, with code of any significant complexity, you soon need to either 
 declare like 19 specific exceptions, or just wrap them into "throws 
 Exception", which is what most people seem to do (at least where I 
 work), at which point the declaration is totally useless, as you can 
 basically get an Exception from any code anyway..

Definitely poor practice. This is most noticeable with APIs like JDBC, where every method throws an SQLException. If you don't like typing try...catch blocks around every exception every time you use it, the solution is to wrap it up in a utility class that handles the exceptions for you.
 
 Third, declared exceptions really fail to work with interfaces well. For 
 example, suppose you have something that can work either with RAM (and 
 can fail with OutOfMemoryError), with a file (IOException) or with a 
 database (SQLException). A common interface will either have "throws 
 Throwable" (totally zero information again), "throws Exception" (almost 
 zero information, and you'll probably forget about OutOfMemory), or 
 nothing, forcing you to wrap those IO/SQLExceptions into 
 RuntimeExceptions, and you'll need to read the docs anyway :)

This is a weak argument. Nothing is stopping you from throwing custom exceptions and attaching the cause to them. Good exception handling code, rather than relying solely on printStackTrace(), will log the entire exception chain to a file. Although I don't agree with your reasoning, I do agree that adding a throws statement to D would be a bad idea. I have often wished that all exceptions in Java were of the runtime variety. As for the original poster's reliance on the compiler to inform him of which exceptions need to be caught, I disagree. I rather do not like it when I compile something and see an error saying that I failed to handle an exception. I always read the documentation for every method I use if it's new to me. IDEs like Eclipse can let you know as you type, but I really do not wish to become dependent upon an IDE (as too many Java programmers are these days). The only downside I can see to not forcing a throws statement is that when someone fails to provide proper documentation, you can't know if a method throws anything or not if you do not have access to the source. But I don't see that as reason enough to add the feature to D. More useful would be a statement that forces people to write documentation. If Walter could come up with that one...
Jan 26 2006
parent xs0 <xs0 xs0.com> writes:
Mike Parker wrote:
 xs0 wrote:
 
 
 specifically remember to wrap it in try/catch. On the other hand,

  > some_string.getBytes("UTF-8")

 will never fail (Java standard mandates support for UTF-8), yet 
 declares a non-runtime exception, so must always be wrapped in 
 try/catch, resulting in unnecessarily ugly code.

"UTF-8" is just one of many possible arguments to this method, so throwing a checked Exception makes sense. Throwing a runtime exception just because one potential argument will never throw wouldn't be a good thing.

I know UTF-8 is just one of many possibilities, but I'm forced to handle a never-occurring exception. Furthermore, with the data-flow checking Java does, I have to do it like this:
 byte[] out=null;
 try {
    out=string.getBytes("UTF-8");
 } catch (UnsupportedEncodingException neverHappens) {}

Notice how it's more than twice as long as
 byte[] out=string.getBytes("UTF-8");

yet does exactly nothing more.
 Second, with code of any significant complexity, you soon need to 
 either declare like 19 specific exceptions, or just wrap them into 
 "throws Exception", which is what most people seem to do (at least 
 where I work), at which point the declaration is totally useless, as 
 you can basically get an Exception from any code anyway..

Definitely poor practice. This is most noticeable with APIs like JDBC, where every method throws an SQLException. If you don't like typing try...catch blocks around every exception every time you use it, the solution is to wrap it up in a utility class that handles the exceptions for you.

That's just as useless. I know nothing more from the fact that it's a SQLException instead of an Exception, except that I caught it when doing a JDBC call (which I probably knew anyway). If the methods were allowed to throw an IOException as well, I would know I should probably try to reconnect and do my query again, but that's not something that can happen, so I either have to always reconnect, never reconnect or ask the user, all of which are worse.
 Third, declared exceptions really fail to work with interfaces well. 
 For example, suppose you have something that can work either with RAM 
 (and can fail with OutOfMemoryError), with a file (IOException) or 
 with a database (SQLException). A common interface will either have 
 "throws Throwable" (totally zero information again), "throws 
 Exception" (almost zero information, and you'll probably forget about 
 OutOfMemory), or nothing, forcing you to wrap those IO/SQLExceptions 
 into RuntimeExceptions, and you'll need to read the docs anyway :)

This is a weak argument. Nothing is stopping you from throwing custom exceptions and attaching the cause to them. Good exception handling code, rather than relying solely on printStackTrace(), will log the entire exception chain to a file.

That's not exception handling, it's merely exception logging. The point I was trying to make is that by fixing the exceptions that can be thrown, you force the implementors of interfaces to wrap all others into either a runtime exception or a declared non-runtime exception (if it even exists), and in both cases information about the real cause is lost, diminishing the program's ability to respond appropriately.
 The only downside I can see to not forcing a throws statement is that 
 when someone fails to provide proper documentation, you can't know if a 
 method throws anything or not if you do not have access to the source. 
 But I don't see that as reason enough to add the feature to D. More 
 useful would be a statement that forces people to write documentation. 
 If Walter could come up with that one...

Agreed :) xs0
Jan 26 2006
prev sibling parent S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-01-26 00:32:26 -0800, nick <nick.atamas gmail.com> said:

 On 2006-01-26 00:06:24 -0800, Sean Kelly <sean f4.ca> said:
 
 nick wrote:
 Keeping it brief:
 
 Shouldn't exception catching be mandatory as in Java?

Why? Exceptions should be allowed to pass as far up the call stack as the programmer wishes them to.

void A() throws Exception {throw Exception("hi");} void B(){A();} // This doesn't work void B() throws Excpetion {A();} // This works So the exception can pass up the call stack, but now the programmer is explicitly aware of what is going on. <snip>blahblahblah<snip>

Is there some problem with looking at the function definition? If it's opaque, this is what DDoc is for. Throws definitions are annoying. -S.
Jan 26 2006
prev sibling parent S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-01-26 00:06:24 -0800, Sean Kelly <sean f4.ca> said:

 void fn() {
      throw new Exception("Surprise!");
 }

ROFLMAO.... I think I've been programming too lone, for some reason I find that hilarious. -S.
Jan 26 2006
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
I am a Java convert.  When I first started using D I found the lack of
requiring try/catches to be disturbing.  However, I now prefer the implicit
manner that D uses.  Why?  With either method, if you're going to be
programming safely, you're going to be putting in appropriate try/catch
blocks that handle exceptions correctly.  With Java, OTOH, I've seen a lot
of stuff like this:
try {
        FileReader fr = ...;
} catch (Exception e)
{
        //Just get the damn thing to compile... Not sure what to do if this
fails
}

Which leads to code that may silently fail.  It's bitten me a few times in
Java.  Of course your response is that the responsible programmer will add
the proper throws clauses to his method signatures to allow the exception
to propogate up, but the responsible programmer will put a try/catch in the
place where it really matters regardless of whether or not he is required
to.

Knowing which exceptions could get thrown is an issue of documentation.

~John Demme

nick wrote:

 Keeping it brief:
 
 Shouldn't exception catching be mandatory as in Java?
 
 If not, then shouldn't functions/methods still have a throws keyword so
 coders know what to catch?
 
 Sorry if this has already been discussed.

Jan 26 2006
parent nick <nick.atamas gmail.com> writes:
 Knowing which exceptions could get thrown is an issue of documentation.

I agree. The question is, how do we enforce the partice of documenting which exceptions are thrown AND make it easily accessible to the programmer. Easily accessible meaning that he/she doesn't have to leave the IDE. Furthermore, how do we create an exception safety net. How about, if "checked" exceptions can go potentially uncaught, there is a compiler warning. I think that's reasonable. Thoughts?
Jan 26 2006
prev sibling next sibling parent reply kris <fu bar.org> writes:
nick wrote:
 Keeping it brief:
 
 Shouldn't exception catching be mandatory as in Java?
 
 If not, then shouldn't functions/methods still have a throws keyword so 
 coders know what to catch?
 
 Sorry if this has already been discussed.
 

For every person who appreciates 'throws', there's another who loathes them. Turns out that programmers are (surprise!) mostly lazy, and tend to wrap a "catchall" around code that javac complains about. Anders (of C# fame) had a lot to say about this aspect, and made some compelling arguments. I understand Gosling has had his doubts upon reflection also. There are a variety of reasons why one would abuse 'throws' (ranging from corporate-pressure to laziness to delusions), and a few that might encourage compliance (purity, 'correctness', long-term management). Which are more motivational in the general case? It doesn't help that a workable 'throws' design often requires ongoing and significant refactoring. The other thing to consider is that D has a different philosophy in terms of 'correctness' enforcement ~ you won't even find a requirement to use the 'override' keyword in the appropriate manner :-D
Jan 26 2006
parent reply nick <nick_member pathlink.com> writes:
There are a variety of reasons why one would abuse 'throws' (ranging 
from corporate-pressure to laziness to delusions), and a few that might 
encourage compliance (purity, 'correctness', long-term management). 

Shouldn't languages target those who want to write clean, workable code? A langauge shouldn't try to accomodate bad programming practices; that's just backwards.
Jan 26 2006
next sibling parent reply "Kris" <fu bar.com> writes:
"nick" <nick_member pathlink.com> wrote..
There are a variety of reasons why one would abuse 'throws' (ranging
from corporate-pressure to laziness to delusions), and a few that might
encourage compliance (purity, 'correctness', long-term management).

Shouldn't languages target those who want to write clean, workable code?

Sure they should. But if/when that becomes abused, it can create a worse situation than the initial state.
 A langauge shouldn't try to accomodate bad programming practices; that's 
 just
 backwards.

Would seem that way. Take a look at the bugs inherent within software, and compare that to hardware. We, as educated and technically capable people, take it for granted when supposedly solid products from the "best software companies in the world" fall over. Yet we scream bloody murder when, say, Intel leaves a bug in their floating point hardware. Why is that? There's a distinct difference in mentality here. Both in the perception of the flaw, and in the propogation of the acceptability. One might be tempted to speculate that hardware companies and employees are "engineers who care about quality, robustness, and dependability". What would one say about software companies in comparison? The upshot is that any language that enforces an 'ideology' is often targeted as a scapegoat, and gains little traction or adoption. Sure, that kind of attitude is full of double-standards and advocates of dubious persuasion. But that's the current climate in software development (IMO). Heck ~ guess what the predominant pushback against 'mandatory override' was, in this very NG? Would you believe "too much typing"? Apparently, people felt that (when overriding a method) the effort of having to type an additional 8 characters, plus a space, far outweighed the benefits of doing so.
Jan 26 2006
parent nick.atamas gmail.com writes:
Well I am all for mandatory override.
There should be - at least - a "good coder mode" that goes ahead and checks for
these things (perhaps a compiler flag). Do you think that's a practical thing to
expect from D?
Jan 26 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
nick wrote:
 There are a variety of reasons why one would abuse 'throws' (ranging 
from corporate-pressure to laziness to delusions), and a few that might 
 encourage compliance (purity, 'correctness', long-term management). 

Shouldn't languages target those who want to write clean, workable code? A langauge shouldn't try to accomodate bad programming practices; that's just backwards.

Perhaps not, but it's arguable whether the lack of throw specs constitutes a "bad programming practice." One thing I don't like about throw specs is that they necessarily tie interface to implementation, which can leave library designers with the difficult choice of whether to change their throw spec if the implementation changes (and thus require all clients to update their code accordingly... which may be an enormous task), or to wrap implementation-specific exceptions before rethrowing them to the client. The first case is probably the correct solution from an idealistic perspective, but it violates the interface stability contract that I believe libraries should adhere to. The second case, however, masks the identity of the underlying exception, so automated error handling is impossible: extern void doSomething() throws SomeException; try { doSomething(); } catch( SomeException e ) { // make sure a FatalException hasn't been wrapped // due to implementation changes for( Exception n = e.next; n; n = n.next ) { // just an example, not entirely certain this does // what I'd like it to if( typeid( n ) == typeid( FatalException ) ) throw n; } // do typical SomeException handling here } The solution I would likely choose is simply to have "throws Exception" as my throw spec, which is no different than what we have now. Sean
Jan 26 2006
parent reply nick.atamas gmail.com writes:
In article <drbafg$1tdq$1 digitaldaemon.com>, Sean Kelly says...
nick wrote:
 There are a variety of reasons why one would abuse 'throws' (ranging 
from corporate-pressure to laziness to delusions), and a few that might 
 encourage compliance (purity, 'correctness', long-term management). 

Shouldn't languages target those who want to write clean, workable code? A langauge shouldn't try to accomodate bad programming practices; that's just backwards.

Perhaps not, but it's arguable whether the lack of throw specs constitutes a "bad programming practice." One thing I don't like about throw specs is that they necessarily tie interface to implementation, which can leave library designers with the difficult choice of whether to change their throw spec if the implementation changes (and thus require all clients to update their code accordingly... which may be an enormous task), or to wrap implementation-specific exceptions before rethrowing them to the client. The first case is probably the correct solution from an idealistic perspective, but it violates the interface stability contract that I believe libraries should adhere to. The second case, however, masks the identity of the underlying exception, so automated error handling is impossible: extern void doSomething() throws SomeException; try { doSomething(); } catch( SomeException e ) { // make sure a FatalException hasn't been wrapped // due to implementation changes for( Exception n = e.next; n; n = n.next ) { // just an example, not entirely certain this does // what I'd like it to if( typeid( n ) == typeid( FatalException ) ) throw n; } // do typical SomeException handling here } The solution I would likely choose is simply to have "throws Exception" as my throw spec, which is no different than what we have now. Sean

How would this scenario be better handled without a throw spec?
Jan 26 2006
parent reply Sean Kelly <sean f4.ca> writes:
nick.atamas gmail.com wrote:
 
 How would this scenario be better handled without a throw spec?

Without a throw spec, the appropriate exception handler will always be called (assuming one exists). Thus: extern void doSomething() throws SomeException; void trySomething() { try { doSomething(); } catch( SomeException e ) { // handle e } } void main() { ... try { ... trySomething(); ... } catch( FatalException e ) { // handle e } ... } Here, the client already had a handler defined for FatalException, so when the implementation of doSomething changed to possibly throw it, the client didn't have to change anything. I'll admit that in some cases the client may have wanted to handle this new exception at a lower level, or had no handler defined at all, but I'm not convinced that throw specs are the correct way to address this issue. On a side note, the DDoc spec already contains "Throws" as a standard section, so there is some incentive to document this properly. Sean
Jan 26 2006
parent reply nick <nick.atamas gmail.com> writes:
 [...SNIP...]
 but I'm not convinced that throw specs are the correct way to address 
 this issue.

 
 On a side note, the DDoc spec already contains "Throws" as a standard 
 section, so there is some incentive to document this properly.

As far as I see it, there are 2 requirements: (1) There must be an easy way to find out exactly what exceptions can be thrown (2) There must be an automatic system that notifies the programmer if he is potentially running into trouble and letting some exceptions go uncaught. Point 1 is addressed by the documentation. Point 2 is not addressed at all by D. Java addresses point 2 by using throw specs. This creates boilerplate code, but eclipse's refactoring facilities make this pretty much a non-issue. So, what do you propose we do about Point 2?
Jan 26 2006
parent reply "Kris" <fu bar.com> writes:
"nick" <nick.atamas gmail.com>
 Point 1 is addressed by the documentation.
 Point 2 is not addressed at all by D.

 Java addresses point 2 by using throw specs. This creates boilerplate 
 code, but eclipse's refactoring facilities make this pretty much a 
 non-issue.

 So, what do you propose we do about Point 2?

I'll propose that an IDE could trace the call-tree(s) and provide that information; perhaps on the fly. One might use the open-source D front-end to help implement such a system?
Jan 26 2006
next sibling parent nick <nick.atamas gmail.com> writes:
Well, I am going to try and bring this to Walter's attention. I think 
it's something that needs to be addressed. (Is there a process for 
this?)

You have made some fairly good arguments regarding the throws 
declaration, and I am convinced that it would be inappropriate to treat 
unhandled exceptions as errors - they should be warnings.

However, after doing some reading and thinking it has become apparent 
that exceptions ARE part of the interface, whether this interface is 
explicitly define via a throws spec or not. As such, I think it fitting 
to explicitly enforce this interface, or at least make the programmer 
very aware of it.

As far as the unfortunate case of try{}catch(Exception e){}, well 
that's just a programming no-no like using gotos and break where they 
don't absolutely belong.
Jan 26 2006
prev sibling parent reply nick <nick.atamas gmail.com> writes:
 I'll propose that an IDE could trace the call-tree(s) and provide that 
 information; perhaps on the fly. One might use the open-source D 
 front-end to help implement such a system?

However, a throw spec would be better performance wise and more explicit.
Jan 26 2006
parent reply David Medlock <noone nowhere.com> writes:
nick wrote:
 I'll propose that an IDE could trace the call-tree(s) and provide that 
 information; perhaps on the fly. One might use the open-source D 
 front-end to help implement such a system?

This thought had occurred to me, and it's certainly high on my list. However, a throw spec would be better performance wise and more explicit.

This clutters up Java to an inane degree and hasn't pointedly helped me in any obvious way. -DavidM
Jan 27 2006
parent reply nick <nick.atamas gmail.com> writes:
On 2006-01-27 04:47:24 -0800, David Medlock <noone nowhere.com> said:

 nick wrote:
 I'll propose that an IDE could trace the call-tree(s) and provide that 
 information; perhaps on the fly. One might use the open-source D 
 front-end to help implement such a system?

This thought had occurred to me, and it's certainly high on my list. However, a throw spec would be better performance wise and more explicit.

This clutters up Java to an inane degree and hasn't pointedly helped me in any obvious way. -DavidM

Throws declarations are good because they let you know (1)what is being thrown and (2)check that you catch it. Throws declarations are bad because they are too strict and maintenance heavy. People dismiss them and this results in worse bugs. A solution would be an automatic on-demand system that gives you all the same features as throws declarations without getting in your way all the time.
Jan 27 2006
parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
nick wrote:
 On 2006-01-27 04:47:24 -0800, David Medlock <noone nowhere.com> said:
  (...)
 A solution would be an automatic on-demand system that gives you all the 
 same features as throws declarations without getting in your way all the 
 time.
 

A lint program for D?
Jan 28 2006
parent nick <nick.atamas gmail.com> writes:
Julio CÚsar Carrascal Urquijo wrote:
 nick wrote:
 On 2006-01-27 04:47:24 -0800, David Medlock <noone nowhere.com> said:
  (...)
 A solution would be an automatic on-demand system that gives you all 
 the same features as throws declarations without getting in your way 
 all the time.

A lint program for D?

of exceptions that a function can throw (this can possibly be read out of the docs for libraries, since the source may not be available).
Jan 29 2006
prev sibling next sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
nick wrote:
 Keeping it brief:
 
 Shouldn't exception catching be mandatory as in Java?
 
 If not, then shouldn't functions/methods still have a throws keyword so 
 coders know what to catch?
 
 Sorry if this has already been discussed.
 

I think the majority of Java programmers (myself included) find checked exceptions to be quite a bad feature. I think this opinion is even becoming a general consensus, even though that won't make the Java language change now (as they are pious about backwards compatibility).
 Shouldn't languages target those who want to write clean, workable code?

Yes, they should, but you are forgeting about the other important aspect: productivity. The problem here, is that while checked exceptions improve code readability, they diminuish coding productivity. The issue then becomes if one thinks the advantadge outweights the disadvantage or not. I think it clearly doesn't, like I said before. Imagine the following scenario: Documenting code is a good pratice right? Now imagine a language feature that required that all functions and datatypes had to be documented, or else the code wouldn't compile. Would that be a good feature to have? And would you write *correct* documentation (and not empty statements), every time you wanted to compile the program? *g* -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Jan 29 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:dr9t6o$gnl$1 digitaldaemon.com...
 Shouldn't exception catching be mandatory as in Java?

 If not, then shouldn't functions/methods still have a throws keyword so 
 coders know what to catch?

I found Bruce Eckel's arguments on this point to be convincing: http://www.mindview.net/Etc/Discussions/CheckedExceptions
Jan 29 2006