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.
