www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP1001: Exception Handling Extensions

reply Superstar64 <Hexagonalstar64 gmail.com> writes:
link: https://github.com/dlang/DIPs/pull/9
file: 
https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md
Jul 10 2016
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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


You don't have to use gc-allocated exceptions anyway.
Allowing to throw any type makes chaining impossible.
Jul 10 2016
parent Superstar64 <Hexagonalstar64 gmail.com> writes:
On Sunday, 10 July 2016 at 20:30:56 UTC, Stefan Koch 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


 You don't have to use gc-allocated exceptions anyway.
 Allowing to throw any type makes chaining impossible.


Can you please explain why it makes chaining impossible?
Jul 10 2016
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
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


Adding another attribute to the language and having the compiler 
do magic behind the scenes?

No thanks.
Jul 10 2016
prev sibling next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Sun, 10 Jul 2016 19:55:37 +0000, Superstar64 wrote:


 link: https://github.com/dlang/DIPs/pull/9 file:
 https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/


DIP1001.md

So if my function calls any runtime functions -- it allocates memory, 
slices an array, etc -- I can't use C-style exception handling. Unless I 
manually do something like:

struct ThrowableWrapper {
  Throwable error;
}
int[] foo(int i) {
  try {
    return [i];
  } catch (Throwable t) {
    throw ThrowableWrapper(t);
  }
}
Jul 10 2016
parent reply Superstar64 <Hexagonalstar64 gmail.com> writes:
On Sunday, 10 July 2016 at 21:43:08 UTC, Chris Wright wrote:

 On Sun, 10 Jul 2016 19:55:37 +0000, Superstar64 wrote:


 link: https://github.com/dlang/DIPs/pull/9 file: 
 https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/


 DIP1001.md

 So if my function calls any runtime functions -- it allocates 
 memory, slices an array, etc -- I can't use C-style exception 
 handling. Unless I manually do something like:

 struct ThrowableWrapper {
   Throwable error;
 }
 int[] foo(int i) {
   try {
     return [i];
   } catch (Throwable t) {
     throw ThrowableWrapper(t);
   }
 }


You could use both c style and d stack unwinding:
---
struct CustomErrorCode
{
     enum __ErrorCode = true;

}

struct CustomUnwind
{

}

int foo(int[] arr, int index) 
 throws(Throwable,CustomErrorCode,CustomUnwind)
{
     auto val = arr[index]; // may throw RangeError with d's 
existing handling
     if (val == 0xdead)
     {
         throw CustomErrorCode(); // throws using new error code 
handling
     }
     else if (val == 0xbad)
     {
         throw CustomUnwind(); // throws using new by value 
unwinding
     }
}
---

Or possible wrap your function in a template that catch Unwind 
exceptions and throws Error Codes.
Jul 10 2016
parent Chris Wright <dhasenan gmail.com> writes:
On Sun, 10 Jul 2016 21:55:04 +0000, Superstar64 wrote:

 You could use both c style and d stack unwinding:


I misread that. The tagged union part applies even if the function can 
throw some types that don't participate in the compile-time error system.
Jul 11 2016
prev sibling next sibling parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
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.
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.
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.

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.
Jul 10 2016
parent Superstar64 <Hexagonalstar64 gmail.com> writes:
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.
Jul 10 2016
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
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


https://forum.dlang.org/post/auplvezvpisiufwvddfo forum.dlang.org
Jul 11 2016
parent reply Seb <seb wilzba.ch> writes:
On Monday, 11 July 2016 at 12:36:59 UTC, Basile B. 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


 https://forum.dlang.org/post/auplvezvpisiufwvddfo forum.dlang.org


 SuperStar64, please ignore the troll(s) and keep working on your 
proposal by incorporating the constructive critic you have 
received so far. As Dicebot already stated it's very important to 
provide good & convincing arguments in favor of your proposal 
because changing a language isn't a simple thing and (may) have 
wide implications.
Jul 11 2016
parent Basile B. <b2.temp gmx.com> writes:
On Monday, 11 July 2016 at 14:44:08 UTC, Seb wrote:

 On Monday, 11 July 2016 at 12:36:59 UTC, Basile B. 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


 https://forum.dlang.org/post/auplvezvpisiufwvddfo forum.dlang.org


  SuperStar64, please ignore the troll(s) and keep working on 
 your proposal by incorporating the constructive critic you have 
 received so far. As Dicebot already stated it's very important 
 to provide good & convincing arguments in favor of your 
 proposal because changing a language isn't a simple thing and 
 (may) have wide implications.


Yes, please get on, even if there's a possibility that you've 
been misleaded by a guy who thinks he's a manager, but is not 
and, maybe has made a "management error".
Jul 11 2016
prev sibling next sibling parent Superstar64 <Hexagonalstar64 gmail.com> writes:
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 too familiar with stack unwinding generation, but would 
generating a separate unwind table for each type(that doesn't 
inherit from Throwable) be faster than the current handling? Is 
it worth adding it to the DIP?
Jul 11 2016
prev sibling next sibling parent Superstar64 <Hexagonalstar64 gmail.com> writes:
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 extended this DIP to add  throws(auto) and inference for auto 
and template functions.
Jul 13 2016
prev sibling parent reply Superstar64 <Hexagonalstar64 gmail.com> writes:
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 decided to close the PR. The my proposal had too many problems 
with it.
Jul 15 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/16/2016 12:51 AM, Superstar64 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 decided to close the PR. The my proposal had too many problems with it.


Work much appreciated. Looks like the new community process works! -- Andrei
Jul 16 2016
parent reply Superstar64 <Hexagonalstar64 gmail.com> writes:
On Saturday, 16 July 2016 at 12:42:49 UTC, Andrei Alexandrescu 
wrote:

 Work much appreciated. Looks like the new community process 
 works! -- Andrei


I'm not sure you understand, I rejected my own PR.
Jul 16 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 17/07/2016 5:35 AM, Superstar64 wrote:

 On Saturday, 16 July 2016 at 12:42:49 UTC, Andrei Alexandrescu wrote:

 Work much appreciated. Looks like the new community process works! --
 Andrei


 I'm not sure you understand, I rejected my own PR.


Exactly! It works :)
Jul 16 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/16/2016 01:35 PM, Superstar64 wrote:

 On Saturday, 16 July 2016 at 12:42:49 UTC, Andrei Alexandrescu wrote:

 Work much appreciated. Looks like the new community process works! --
 Andrei


 I'm not sure you understand, I rejected my own PR.


Understood. Wasn't that due to the community feedback you got? -- Andrei
Jul 18 2016