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
>
