The Right Approach to Exceptions

[Jose Armando Garcia]

On Sat, Feb 18, 2012 at 10:46 PM, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
> 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(...) {...}
>        }
>

You basically agree that we need error codes inside the exception to
handle database errors correctly. What about POSIX error codes?
Basically in some cases you are solving the problem using inheritance
in other cases you are solving the problem by switching on a variable.

> 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??
>

Just worry about what you know and don't know...

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