The Right Approach to Exceptions

[H. S. Teoh]

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

-- 
My program has no bugs! Only undocumented features...