The Right Approach to Exceptions

[H. S. Teoh]

On Sat, Feb 18, 2012 at 10:21:17PM -0200, Jose Armando Garcia wrote:
> On Sat, Feb 18, 2012 at 9:13 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
> > On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
> > GetOptException
> > FlagArgumentMissingException
> > InvalidFlagArgumentException
> > UnknownFlagException
> > FileException
> > FileNotFoundException
> > NotFileException
> > NotDirException
> > AccessDeniedException
> >
> > I died inside a little.
> 
> Yeah. This gets even worse by the fact that some times you have to
> import vendor specific modules with their own set of exceptions. For
> example the JDBC exception model was just a nightmare. Depending on
> which database driver you used you could have a completely different
> set of exceptions you had to catch.
> 
> The Spring Framework solved this problem by just throwing just one
> exception: SQLException (if my memory serves me right). The developer
> then had to switch based on the driver type and the error code. I
> don't think this is perfect but I think it works much better in
> practice.

That simply means Phobos has to be designed such that vendor-specific
modules throw exceptions that inherit from SQLException.

This is merely the symptom of a poorly-designed exception hierarchy, not
of the fact that there is a hierarchy.


> The other nice thing about this model is that it is easier to know
> which error you want to handle. Database vendor document their errors
> using error code not language specific exception. If the Oracle manual
> says that the database gives error XXXX for such and such condition
> how in the world do you know to which JDBC exception does that match
> or D exception, etc.?

Simple. By doing this:

	class OracleException : SQLException {
		OracleErrorCode_t code;
		this(...) {...}
	}

Then if your code just wants to handle generic SQL errors, you catch
SQLException. If your code is ready to deal with Oracle error codes,
then catch OracleDriverException and process the code.

Just because some other exception *may* derive from OracleException
doesn't mean you have to specifically catch that. Just catch the base
class and read the error code yourself. That's what a class hierarchy is
for!!

I can't believe something this simple has to be explained so
elaborately. I thought all of us here knew how to use OO??


T

-- 
"You know, maybe we don't *need* enemies." "Yeah, best friends are about
all I can take." -- Calvin & Hobbes