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.


Agreed. There is no contradiction:

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...]


Having a throw spec lets the programmer know at compile time exactly 
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.


 Agreed. There is no contradiction:
 
 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 

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.


Right, so what is 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.


That's good, but not good enough.

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?


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.
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.
 
 
 


If your suggestion is a *required* throws declaration, I will disagree. 
  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.
 
 
 


 If your suggestion is a *required* throws declaration, I will disagree. 
   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?


Basically, yeah. And in addition and IDE feature which brings up a list 
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