DIP1001: Exception Handling Extensions

[Superstar64 via Digitalmars-d-announce]

On Sunday, 10 July 2016 at 21:52:37 UTC, Lodovico Giaretta wrote:
> On Sunday, 10 July 2016 at 19:55:37 UTC, Superstar64 wrote:
>> link: https://github.com/dlang/DIPs/pull/9
>> file: 
>> https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md
>
> I'm not convinced by this proposal. Here are some early 
> thoughts:
>
> 1) Wouldn't a library solution based on functional-style tagged 
> results achieve the same without changing the language and 
> making things less clear (see my other points)? Something on 
> the lines of variant?
> 2) Wouldn't this make code quite obscure? I mean, now if you 
> see a throw or a catch you know what's going on. With this 
> proposal, when you see a throw or a catch, you have to go look 
> at the declaration of the thrown or catched type to get what's 
> going on.

This proposal allows you to switch between error code handling and
stack unwinding by just switching one line of code.

> 3) From your proposal, it seems that current exception handling 
> needs the GC, which is not true; you can already do exception 
> handling in @nogc code, without any extra quirk.

Wouldn't that still require allocation for the exception's message
and stack trace?

> 4) C++ deprecated throw lists; while this does not 
> automatically mean that they are bad, we shall learn from 
> others' errors, and be very careful.

Throw lists where added because they are required for this to
work with incremental compilation.

> But all of this is just my opinion based on a fast read of the 
> proposal.
>
> P.S.: something went wrong (probably with copy-pasting) here:
>> A function which calls a sub function with a @throws(TypeList) 
>> attribute must have
>> alluncaught possible exceptions must be a part of the 
>> @throws(TypeList) attribute of the
>> caller function.

Nothing wrong on my end.