The Right Approach to Exceptions

[Robert Jacques]

On Sat, 18 Feb 2012 19:13:02 -0600, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Saturday, February 18, 2012 19:01:31 Robert Jacques wrote:
>> That an argument of an internationalization module as part of the standard
>> library, not for or against a particular exception module. I don't know
>> what a good/robust module would look like, but many open source projects
>> simply use a global string[string] and it seems to work okay for them.
>
> It's an argument against making it so that the only way to get the error
> information from an exception is toString.
>
> Exception handling is far more flexible when the exception's type and member
> variables gives you the information you need to actually handle the exception
> - or in the case of internationalization, generate your own error message. But
> ideally, users wouldn't see the result of an exception's toString regardless
> (especially since that includes stuff like the stack trace). Not even the msg
> field is really acceptable for that IMHO. It's great for debugging and maybe
> log messages, but not dealing with the user. To deal with the user
> appropriately, you need to know _what_ went wrong in a way that your program
> can process it and react appropriately, which strings just don't do.
>
> - Jonathan M Davis

But you _always_ know what went wrong: An unexpected error occurred while trying to do X, where X is whatever is inside the try-catch block. Exceptions are for exceptional situations and not supposed to be used as a form of out of band information return (or at least that's what every programming book tells me). I see typed exceptions as having a strong coupling problem; exception handling that is aware enough to handle a typed exception, is so close to the exception generation code that most of the information conveyed by the 'type' is also conveyed by the context. Now, the further away exception handling gets from exception generation, the less information context coveys, but the ability of the handler to do anything smarter than log the exception and retry / cancel becomes less and less. The other issue I see with typed exceptions is that the classic 'is a' relationship seems weak; to be informative and useful and exception must map to a specific or small set of error/unexpected  
conditions. However, this specificity naturally leads to large number of final classes, which isn't really leveraging OO principals. It's hard to see what, if any, benefit the intermediate base classes give over a generic exception.