The Right Approach to Exceptions

Juan Manuel Cabo juanmanuel.cabo at
Mon Feb 20 12:10:13 PST 2012

With all due respect, I don't see module exception categories
as something good for the categorization of exceptions.

As I said in a previous post, long lost in this mega thread,
please don't create exception categories, unless it makes
sense to write a   catch (MyNewShinyCategory ex) {}  for it.
An artificial category would be in the way of other criteria
that aids catch grouping better.
(For instance, many different modules might want to add a
kind of IOException (not that I advocate the IOException
category, this is just for illustration))


On 02/20/2012 01:45 PM, Andrei Alexandrescu wrote:
> On 2/20/12 10:37 AM, foobar wrote:
>> On Monday, 20 February 2012 at 15:50:08 UTC, Andrei Alexandrescu wrote:
>>> Actually that just shuffles the matter around. Any setup does demand
>>> that some library (in this case most probably the standard library) will
>>> be a dependency knot because it defines the hierarchy that others should
>>> use.
>> Not accurate. A 3rd party library that want to be compatible will no
>> doubt depend on the standard library's _exception hierarchy_ but that
>> does *not* mean it should depend on the parallel functionality in the
>> standard library. Per our example with IO, if I use I certainly
>> do not want my application code to include redundantly both and
>> I wanted to use as an *alternative* to
> This is a confusion. Using PackageException!"" does not require importing Conversely, using
> std.IOException _does_ require importing std.exceptions or whatnot. So from a dependency management viewpoint,
> PackageException is superior to IOException.
> The converse disadvantage is that typos won't be caught during compilation. For example, using PackageException!""
> will go through no problem, but of course won't be caught by people waiting for a PackageException!"".
> Andrei

More information about the Digitalmars-d mailing list