Hi everyone.
I previously made the dub package https://georgy7.github.io/exceptions/exceptions.html
because many languages have the useful standard NotImplementedException (UnsupportedOperationException), ArgumentException (IllegalArgumentException), IOException. It's easy to catch by type.

What do you thing about to include these three exceptions in Phobos as the base for user exceptions.

Maybe, ArgumentException is not very suitable name for an exception in D, because the language has the contracts. So, actually, an assert will throw an Exception, when there is a bad argument, isn't it?
When we use IllegalArgumentException in Java at work, we actually mean "bad user input" in most cases. So, I would name it UserInputException.

Also, I saw the DIP33 https://wiki.dlang.org/DIP33
It proposes the complex class hierarchy. I have no thoughts about it.

Well, I just suggest to add these 3 classes in std.exception.

NotImplementedException : Exception
UserInputException : Exception
IOException : Exception

What do you think?

Does anybody know if we've solved @nogc exceptions? (I haven't needed them).
If we haven't we should hold off on this.

On Thursday, March 23, 2017 09:31:23 Георгий via Digitalmars-d wrote:
> Well, I just suggest to add these 3 classes in std.exception.
>
> NotImplementedException : Exception
> UserInputException : Exception
> IOException : Exception
>
> What do you think?

IMHO, an exception about something not being implemented is indicative of a bad design. If a class implements an interface, it should implement all of the functions of that interface, or there's a bug in the design. Similarly, if a function exists but has no implementation yet, it should use assert(0). Promoting any kind of exception for "not implemented" as being standard seems like a completely terrible idea to me.

As for the others, I think that they're so generic that you might as well just use Exception. It makes a lot more sense to me to use specific exceptions for specific use cases, not general use cases. For the type to matter, it has to be something that you're going to operate on differently than you would other exception types, and that implies that they're tied to fairly specific error conditions and not anything general. So, I don't think that we should be adding more exception types to Phobos without a really good reason for it, and if we do, it's likely for something that's specific to a particular portion of Phobos rather than for general use. I think that adding new exceptions to std.exception is exactly the wrong thing to be doing.

- Jonathan M Davis

On Thursday, March 23, 2017 22:39:14 rikki cattermole via Digitalmars-d wrote:
> Does anybody know if we've solved @nogc exceptions? (I haven't needed them). If we haven't we should hold off on this.

If we have any hope of solving that, it's going to depend on the built-in reference counting that hasn't been implemented yet (I believe that it's on hold while Walter works on sorting out @safe issues that need to be fixed first). Other than that, AFAIK, the only solutions involve either pre-allocating exceptions (which works for some cases but is often counter-productive as far as error-reporting goes) or allocating with malloc (and that only works in isolated circumstances where everyone working on the code is well aware of the fact that the exceptions are being allocated via malloc and know how to handle that in that code base; otherwise, it's just going to cause memory leaks and @safety problems).

- Jonathan M Davis

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.

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.

On Thursday, 23 March 2017 at 10:26:38 UTC, rikki cattermole 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.

I never supposed to catch NotImplementedException, but use it as assert(0). Well, maybe only at top level of web page rendering in a web framework to show an error message and log the stack trace.

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

On Thursday, 23 March 2017 at 10:36:42 UTC, Георгий wrote:
> On Thursday, 23 March 2017 at 10:26:38 UTC, rikki cattermole wrote:
>> On 23/03/2017 11:20 PM, Георгий wrote:
>
> I never supposed to catch NotImplementedException,

I mean, I never meant to use it this way.
So, assert(0) is much better for most of applications.

But the exception may still be usable with web frameworks.
https://github.com/rejectedsoftware/vibe.d/issues/666

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.