The Right Approach to Exceptions

Juan Manuel Cabo juanmanuel.cabo at
Mon Feb 20 17:32:48 PST 2012

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

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?

This is a universal problem with transversal traits of exceptions.


On 02/20/2012 10:22 PM, H. S. Teoh wrote:
> On Mon, Feb 20, 2012 at 10:01:03PM -0300, Juan Manuel Cabo wrote:
> [...]
>> Back to the nasty argument. I think that the example that everyone
>> wants is this one. If anyone solves this one without Variant[string]
>> then it's a better solution than Variant[string]. (I repaste it
>> from an above reply I gave):
>>   [..]
>>   For instance: a C library wrapper, which gets the library errors encoded
>>   as some error code and throws them as exceptions. Shouldn't the library
>>   throw a FileNotFoundException when that's the error, instead of throwing
>>   a LibraryException that has the error code in a field?
>>   So the correct thing to do is: after a library call, the wrapper
>>   checks the last error code number with a switch statement, and deciding
>>   which standard exception type to throw (defaulting to whatever you like
>>   if the error code doesn't map to a standard D exception). Then you
>>   add the error code to the Variant[string], and any other extra info.
> But why bother with the error code at all? If you get a
> FileNotFoundException, you already know all there is to know about the
> problem, adding errno to it is redundant and only encourages code that's
> bound to a specific implementation.
> Instead, Phobos should present a self-consistent API that's independent
> of what it uses to implement it, be it C stdio (errno) or C++ iostreams
> or Oracle driver (Oracle-specific error codes) or Postgresql driver
> (Postgresql-specific error codes), or what have you.
> For error codes that *don't* have a direct mapping to standard
> exceptions, you can just encapsulate the errno (or whatever) inside a
> specific catch-all exception type dedicated to catch these sorts of
> unmapped cases, so that code that *does* know what errno can just catch
> this exception and interpret what happened. General,
> platform-independent code need not know what this exception is at all,
> they can just treat it as a general problem and react accordingly.  We
> don't (and shouldn't) expect every app out there to know or care about
> the errno of a failed operation, especially if it doesn't map to one of
> the standard exception types.
>>   That way, exception types can be standard.
>>   So, to keep D exception types standard reusable and respected by
>>   future code, you must follow the Open-Closed design principle
>>   (nicest principle of OO design ever).
>>   [..]
>> Adding the Variant[string] is considered applying the great
>> Open-Closed Design Principle:
>> 	-Open for reuse.
>> 	-Closed for modification.
> [...]
> Please bear in mind, I'm not saying that Variant[string] is *completely*
> useless. I'm just saying that most of the time it's not necessary. Sure
> there are some cases where it's useful, I've no problem with it being
> used in those cases. But we shouldn't be using it for all kinds of stuff
> that can be handled in better ways, e.g., static fields in a derived
> exception class.
> T

More information about the Digitalmars-d mailing list