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