More exception classes into Phobos?

[Jonathan M Davis via Digitalmars-d]

On Friday, March 24, 2017 00:14:33 rikki cattermole via Digitalmars-d wrote:
> On 24/03/2017 12:09 AM, Jonathan M Davis via Digitalmars-d wrote:
> > On Thursday, March 23, 2017 23:26:38 rikki cattermole via Digitalmars-d
> >
> > wrote:
> >> On 23/03/2017 11:20 PM, Георгий wrote:
> >>> On Thursday, 23 March 2017 at 09:48:54 UTC, Jonathan M Davis wrote:
> >>>> On Thursday, March 23, 2017 09:31:23 Георгий via Digitalmars-d wrote:
> >>>>
> >>>> If a function exists but has no implementation yet, it should use
> >>>> assert(0).
> >>>
> >>> I didn't know that.
> >>
> >> That will throw an AssertError. You should try not to catch Error's.
> >> So there still needs to be an exception of some kind.
> >
> > My point was that it's bad design to be throwing an exception because
> > something isn't implemented. If something isn't implemented, it's a bug.
> > assert(0) is a great way to indicate that something isn't implemented
> > yet
> > and have the program die (like it should) if that function inadvertently
> > gets called.
> >
> > I know that there are cases in Java land where folks (even the standard
> > library in some cases) have a class implement an interface but not truly
> > implement all of it and have the functions that aren't properly
> > implemented throw an exception. But I don't see how that can be
> > anything but bad design, and I don't think that we should be promoting
> > such behavior in D's standard library.
> >
> > - Jonathan M Davis
>
> Nobody said that there had to be code in Phobos that used it, just a
> standard set of exceptions for a variety of purposes. That is what was
> proposed.

My point was that having an exception for something that is not implemented
like Java did is a horrible design mistake and thus should not be promoted
by D's standard library. Classes should not be implementing interfaces only
to throw exceptions when they don't really want to be implementing some of
the functionality of that interface. That's just plain bad design.

If a programmer is looking to temporarily indicate that a function is
unimplemented, then normally, the correct thing to do is to assert(0). And
even if a programmer has a use case where it makes sense to temporarily
throw an exception due to a lack of implementation rather than considering
it a bug to call an unfinished function, then that's something internal to
their application and thus not part of any public API and thus would not
need to be standard.

As for the other proposed exceptions such as IOException, I think that
they're so generic as to be borderline useless. When you catch an exception,
it has to be specific enough to what you're calling to actually be able to
rely on what it means and actually be able to react to it differently based
on its type, and "something related to I/O somewhere in the chain of
functions that I just called just failed" isn't really much different from
"something somewhere in the chain of functions that I just called just
failed," which is basically the difference between IOException and
Exception, especially if IOException is used by a bunch of different
libraries all over the place, whereas if it's specific to a library that
you're using, at least you can rely on where it came from and thus rely on
what it means on some level.

I honestly think that trying to standardize exceptions is a bad idea. They
_should_ be specific to specific libraries or applications, otherwise
they're not much different from just throwing Exception.

- Jonathan M Davis