The Right Approach to Exceptions

Andrei Alexandrescu SeeWebsiteForEmail at
Mon Feb 20 07:50:08 PST 2012

On 2/20/12 3:01 AM, foobar wrote:
> On Monday, 20 February 2012 at 07:10:39 UTC, 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!"") {...} } catch
>>> (PackageException!"") {...} } catch
>>> (PackageException!"") {...} ...
>>> What the hell is wrong with just using an IOException?
>> There's nothing wrong, but there's a possible misunderstanding. If
>> and cooperate with std, then they'd originate
>> exceptions in (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!"" or IOException.
> The above is patently wrong. Are you suggesting that and
> need to depend on Phobos IO?? If so, that removes the
> benefits of using 3rd party libraries. If that's not your intention
> (and I really hope it isn't!) than IOException must be defined in a
> *separate* module that tango can depend on.

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

> [Meta] side-note: It's extremely irritating when you demand utmost
> pedantic reasoning from others while you often answer without
> providing such pedantic reasoning yourself or worse answer with a
> single word posts. That shows a complete lack of respect for others.
> You seem to be of high regard for yourself which is not justified at
> all given this attitude.

When giving brief answers I was trying to maximize throughput in a 
couple of cases when the meaning was obvious from the context. Otherwise 
I do my best to elaborate my points. But I see how that can be 
irritating, I won't continue it.


More information about the Digitalmars-d mailing list