The Right Approach to Exceptions

[H. S. Teoh]

On Mon, Feb 20, 2012 at 10:32:48PM -0300, Juan Manuel Cabo wrote:
> Well... then why did this mistakes exist?:
> 
> In dot NET:
> 
> 	ComException - Exception encapsulating COM HRESULT information
>         SEHException	Exception encapsulating Win32 structured exception handling information.z
> 
> 	http://msdn.microsoft.com/en-us/library/z4c5tckx%28v=VS.71%29.aspx

I couldn't tell you, I didn't design this.


> And why do you think that a thing like standardizing DatabaseException
> never survives users, and that each database manager library defines
> its own top *DatabaseException base class?

Perhaps because when users chose to use the Oracle engine, they want to
deal with Oracle-specific features including Oracle error codes
directly? So a generalized SQL exception designed under some idealized
database framework would only get in their way?


> This is a universal problem with transversal traits of exceptions.
[...]

True, so now we're trying to fix this by having *both* an exception
class hierarchy *and* what amounts to a generic varbind that stores
transversal information?

If Oracle error codes are what the user wants, then giving them a pretty
exception class hierarchy is sorta pointless. They just want an
OracleException containing the Oracle error code. They couldn't care
less if there was a SQLParseErrorException or a
SQLCannotAcquireLockException. It would be a waste of effort to build a
pretty hierarchy for them if they're just going to ignore it and use
Oracle error codes anyway.

If we're really trying to solve transversal problems, then I have the
feeling that this will require something more than just slapping a
Variant[string] onto the Exception class. We need to re-examine the
entire model of what exceptions are and what's the best way to deal with
them.

In the case of Phobos, we're not really dealing with the same kind of
situation (not yet, anyway). Phobos modules, in general, aren't merely
thin wrappers around a self-contained external module the same way an
Oracle API is just a thin wrapper over an independent Oracle driver
built by an independent party.  So we get to define our own game, in a
sense.  There's no Oracle error code to map, and we can enforce the
proper use of an exception class hierarchy. If someone wants direct
access to errno, say, they could just call the C API directly -- D was
designed not to require wrappers in that case.

But still, I concede that class hierarchies don't solve everything.
Sometimes we do need something more. But slapping on a Variant[string]
onto the existing system seems like merely a workaround, not a real
solution.


T

-- 
Study gravitation, it's a field with a lot of potential.