Question about exception specification

[Christopher Wright]

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.