The Right Approach to Exceptions
Juan Manuel Cabo
juanmanuel.cabo at gmail.com
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
http://msdn.microsoft.com/en-us/library/z4c5tckx%28v=VS.71%29.aspx
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.
--jm
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.
>> http://www.objectmentor.com/resources/articles/ocp.pdf
> [...]
>
> 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