The Right Approach to Exceptions

[H. S. Teoh]

On Mon, Feb 20, 2012 at 01:10:39AM -0600, Andrei Alexandrescu wrote:
> On 2/20/12 12:44 AM, foobar wrote:
> >I just died a little reading this. Are you suggesting that in order
> >to handle IO exceptions I need to: try { ...whatever... } catch
> >(PackageException!"std.io") {...} } catch
> >(PackageException!"tango.io") {...} } catch
> >(PackageException!"otherLib.io") {...} ...
> >
> >What the hell is wrong with just using an IOException?
> 
> There's nothing wrong, but there's a possible misunderstanding. If
> tango.io and otherLib.io cooperate with std, then they'd originate
> exceptions in std.io (as opposed to their own). Do note that the issue
> is exactly the same if libraries use IOException - they all must agree
> on using the same nomenclature, whether it's called
> PackageException!"std.io" or IOException.
[...]

The exception hierarchy and the phobos module hierarchy are two
different things. They should not be unnecessarily coupled.

You *want* exceptions in the exception hierarchy to be maximally
reusable by code OUTSIDE of the phobos module that first introduced
them. You want things like ParseError and LexicalError instead of
StdGetoptError and StdJsonLexicalError, because then user code can
*reuse* these exception types! *That* is what reduces boilerplate, since
otherwise user code would have to define their own exceptions, thereby
incurring lots of boilerplate and code duplication.


> ModuleException and PackageException have one important thing going for
> them: they automate away a good amount of boilerplate, which makes them
> interesting for me to look at, and worth sharing as long as we're
> brainstorming. The associated issues as clear as the advantages.
> Probably ModuleException is too specific to be interesting, but
> PackageException seems useful.
[...]

They do not automate away boilerplate; they merely transplant said
boilerplate into user code by making it impossible for user code to
reuse these exceptions. Which actually amounts to *more* boilerplate,
since every user app will be introducing their own exception types
rather than reusing what's already in the standard library.


T

-- 
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next. -- (Stolen from the net)