The Right Approach to Exceptions

[Juan Manuel Cabo]

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))

--jm


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 tango.io I certainly
>> do not want my application code to include redundantly both std.io and
>> tango.io. I wanted to use tango.io as an *alternative* to std.io.
> 
> This is a confusion. Using PackageException!"std.io" does not require importing std.io. 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!"sdt.io"
> will go through no problem, but of course won't be caught by people waiting for a PackageException!"std.io".
> 
> 
> Andrei
>