On Thursday, 23 March 2017 at 11:09:33 UTC, Jonathan M Davis wrote:
>
> 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 don't agree. On the web, in production, even if this is a bug,
the page may down, the request may down, but not entire application.

On Thursday, 23 March 2017 at 11:15:45 UTC, Георгий wrote:
> On Thursday, 23 March 2017 at 11:09:33 UTC, Jonathan M Davis wrote:
>>
>> 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 don't agree. On the web, in production, even if this is a bug,
> the page may down, the request may down, but not entire application.

And more importantly, the server should return a HTTP status indicating that there was a problem and that the request should not be repeated. Just silently dying does not work as well in a bigger setting where you want other services to adapt.

On 24/03/2017 12:29 AM, Ola Fosheim Grøstad wrote:
> On Thursday, 23 March 2017 at 11:15:45 UTC, Георгий wrote:
>> On Thursday, 23 March 2017 at 11:09:33 UTC, Jonathan M Davis wrote:
>>>
>>> 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 don't agree. On the web, in production, even if this is a bug,
>> the page may down, the request may down, but not entire application.
>
> And more importantly, the server should return a HTTP status indicating
> that there was a problem and that the request should not be repeated.
> Just silently dying does not work as well in a bigger setting where you
> want other services to adapt.

And even better, have it damn well logged!

On Thursday, 23 March 2017 at 11:56:45 UTC, rikki cattermole wrote:
> On 24/03/2017 12:29 AM, Ola Fosheim Grøstad wrote:
>> On Thursday, 23 March 2017 at 11:15:45 UTC, Георгий wrote:
>>> On Thursday, 23 March 2017 at 11:09:33 UTC, Jonathan M Davis wrote:
>>>> [...]
>>>
>>> I don't agree. On the web, in production, even if this is a bug,
>>> the page may down, the request may down, but not entire application.
>>
>> And more importantly, the server should return a HTTP status indicating
>> that there was a problem and that the request should not be repeated.
>> Just silently dying does not work as well in a bigger setting where you
>> want other services to adapt.
>
> And even better, have it damn well logged!

O God, not again, please!

On Thursday, 23 March 2017 at 11:56:45 UTC, rikki cattermole wrote:
> And even better, have it damn well logged!

Yes, all failed asserts should be logged with a stacktrace and the context that caused it to trigger (e.g. the initiating HTTP request that triggered the failure).

On Thursday, 23 March 2017 at 09:31:23 UTC, Георгий wrote:
>
> NotImplementedException : Exception
> UserInputException : Exception
> IOException : Exception

I am not sure already, NotImplementedException should be in Phobos. Something like this may be a part of vibe.d.

But I still vote for two others. Especially for IOException.
It's too common! It needed everywhere. Why every library, that works with streams, need to implement its own exception class for this?

On 24/03/2017 1:11 AM, Георгий wrote:
> On Thursday, 23 March 2017 at 09:31:23 UTC, Георгий wrote:
>>
>> NotImplementedException : Exception
>> UserInputException : Exception
>> IOException : Exception
>
> I am not sure already, NotImplementedException should be in Phobos.
> Something like this may be a part of vibe.d.
>
> But I still vote for two others. Especially for IOException.
> It's too common! It needed everywhere. Why every library, that works
> with streams, need to implement its own exception class for this?

I want to hear what Walter&Andrei have to say about memory management before we start deciding about which if any should be implemented.

My suspicion is that we would need some specific logic to make the memory management quite nice here which would require logic changes. So anything done right now would be silly.

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

On 3/23/2017 9:44 AM, Jonathan M Davis via Digitalmars-d wrote:
> 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.

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.

On 2017-03-23 20:47, Walter Bright 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.

A plain Exception is completely useless, it can just as well be an assertion instead. Because it's not possible to extract any information from the exception (except for trying to parse the message which is a bad idea) resulting in not being able to act on a thrown exception. Which then results in it being pointless to catch the exception in the first place.

I think it's a bad design that it's possible created instances of Exception, it should either be an abstract class or an interface.

-- 
/Jacob Carlborg