www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Question about exception specification

reply Graham St Jack <grahams acres.com.au> writes:
I read WalterAndrei.pdf recently, and liked most of what was in there.

However, there was the line: "Exception specifications: bad idea" on a 
slide that discussed a possible nothrow keyword.

Can anyone explain why they are a bad idea? And if they are in fact a 
bad idea, how do I find out what exceptions can be thrown by a function? 
Eyeballing heaps of code doesn't count as a way!
Oct 23 2007
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Graham St Jack wrote:
 I read WalterAndrei.pdf recently, and liked most of what was in there.
 
 However, there was the line: "Exception specifications: bad idea" on a 
 slide that discussed a possible nothrow keyword.
 
 Can anyone explain why they are a bad idea? And if they are in fact a 
 bad idea, how do I find out what exceptions can be thrown by a function? 
 Eyeballing heaps of code doesn't count as a way!

Exception specifications require me to put implementation details in my interfaces. Exception specifications in Java make me do a little joyful dance whenever I realize that a third-party library component throws only runtime exceptions. Exception specifications require me to write extra code for normal behavior. Exception specifications are born of a wrongheaded notion that every function wants to be entirely reliable, not just every program. Exception specifications in a complex application make me write "void foo () throws Exception" because I don't want to enumerate the half dozen possible exceptions for this function to throw. I could just always use runtime exceptions. Then I just (JUST) have to catch all other exceptions from third parties and rethrow them as runtime exceptions. What's good about exception specifications? They remind me that things can go wrong. But usually I only want to check for the usual and obvious stuff (the user wants me to open this file; does it exist and does the user have read permissions?). If I want a very reliable program, I'll make main nothrow, then descend the call tree to keep error handling close to the error. Most projects aren't quite so reliable and can't afford that much effort on error handling, and exception specification becomes a source of bitterness and annoyance.
Oct 23 2007
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Graham St Jack Wrote:

 I read WalterAndrei.pdf recently, and liked most of what was in there.
 
 However, there was the line: "Exception specifications: bad idea" on a 
 slide that discussed a possible nothrow keyword.
 
 Can anyone explain why they are a bad idea? And if they are in fact a 
 bad idea, how do I find out what exceptions can be thrown by a function? 
 Eyeballing heaps of code doesn't count as a way!

It's been debated ad infinitum, and there are definite advantages to exception specification, especially in smaller projects. For a large project, though, the general consensus I think is that it reduces productivity considerably while not giving much significant advantage, and it encourages bad programming practices such as: try { // Do stuff } catch(Exception e) { // ignore } ... just to avoid exception specification, since the place you actually deal with an exception, in a very large project, could be 9 calls up th hierarchy. It also makes functors, function pointers, closures, delegates, etc. hard to implement. As for how to determine which exceptions a function throws, that information belongs in the documentation of the function. FWIW, I agree that for smaller projects/functions, exception specification works quite well. As for how to determine what
Oct 23 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Graham St Jack wrote:
 I read WalterAndrei.pdf recently, and liked most of what was in there.
 
 However, there was the line: "Exception specifications: bad idea" on a 
 slide that discussed a possible nothrow keyword.
 
 Can anyone explain why they are a bad idea? And if they are in fact a 
 bad idea, how do I find out what exceptions can be thrown by a function? 
 Eyeballing heaps of code doesn't count as a way!

Check this link for a good article about checked exceptions: http://www.mindview.net/Etc/Discussions/CheckedExceptions If you are coding in Java, it also offers a good way to deal with checked exceptions. (much better than just catching and ignoring, hoping to deal with it later) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 26 2007
parent Graham St Jack <grahams acres.com.au> writes:
Excellent article, thanks

Bruno Medeiros wrote:
 Graham St Jack wrote:
 I read WalterAndrei.pdf recently, and liked most of what was in there.

 However, there was the line: "Exception specifications: bad idea" on a 
 slide that discussed a possible nothrow keyword.

 Can anyone explain why they are a bad idea? And if they are in fact a 
 bad idea, how do I find out what exceptions can be thrown by a 
 function? Eyeballing heaps of code doesn't count as a way!

Check this link for a good article about checked exceptions: http://www.mindview.net/Etc/Discussions/CheckedExceptions If you are coding in Java, it also offers a good way to deal with checked exceptions. (much better than just catching and ignoring, hoping to deal with it later)

Oct 27 2007