More exception classes into Phobos?

[Jonathan M Davis via Digitalmars-d]

On Thursday, March 23, 2017 12:47:29 Walter Bright via Digitalmars-d wrote:
> On 3/23/2017 9:44 AM, Jonathan M Davis via Digitalmars-d wrote:
[...]
> Thanks for expressing this better than I could have. Over time I've found
> that standardized Exception types seem to become less and less useful
> over just using "Exception" with an appropriate message.

I used to think that standard exceptions made sense - I may have even argued
as much in a discussion or two in this newsgroup years ago - but over time,
I've come to the conclusion that they would be detrimental. I find that in
most cases, either all I care about is that something went wrong (in which
case, Exception is enough), or I need to know fairly specifically what went
wrong so that I can respond differently based on what went wrong, and in
those cases, a standard exception wouldn't be any different from Exception.
It simply wouldn't provide the information that I need. It can make sense
when additional information is provided (like we do with ErrnoException or
SocketOSException), but that's often primarily to aid in construction of the
exception type rather than really having any effect on how you handle it.

What I'm increasingly on the fence about is exceptions that are specific to
modules or libraries but don't really provide any additional information
over what you get with Exception. We have several instances of this in
Phobos (e.g. DateTimeException and URIException), and I've often done it
with libraries where the entire library or a section of the library has a
specific exception type. That helps indicate where the exception originates
from (though stack traces obviously hepl with that), and it allows you to
catch exceptions based on which library or section of a library is mad at
you (which is sometimes useful), but often, it's not much different from
just using Exception. To an extent, it depends on what functionality is
getting its own exception, and usually, the more narrow that is, the more
useful the exception type is, but ultimately, I don't know what the best
approach is with such exception types.

Where specific exceptions definitely make sense is stuff like FileException
or SocketOSException, which provide additional information as to what went
wrong - or GetOptException, where knowing what piece of functionality is mad
at you is exactly what you need to know. Exception types like IOException or
InvalidArgumentException simply don't tell you enough to do reliably respond
to them based on what they're telling you - _especially_ if every library
under the sun could be throwing them at you. At least if they were specific
to a particular library, then you'd know what section of code is screaming
at you, and that combined with the general type of exception might be enough
to do something useful, even if the type of the exception is overly generic.

- Jonathan M Davis