Hi all,

Weka is using a modified druntime. One of the modifications is adding a function that you can use to query whether an exception is "in flight"

```
/****************************************
 * Returns true when an exception is "in flight", where "in flight"
 * means that an exception has been thrown but has not been caught yet.
 *
 * Returns:
 *      true when an exception is "in flight" or not.
 */
extern(C) bool _d_eh_isExceptionInFlight()
```

The function is not exposed to the outside world, but knowledgeable coders can access it using an extern(C) forward declaration.

Is this generally useful functionality and shall I upstream this to druntime? I have not looked at whether this is easy to implement for the Windows exception handling.
If not, then I will upstream it to LDC's druntime fork.

thanks,
  Johan

On 10/20/20 10:56 AM, Johan wrote:
> Hi all,
> 
> Weka is using a modified druntime. One of the modifications is adding a function that you can use to query whether an exception is "in flight"
> 
> ```
> /****************************************
>   * Returns true when an exception is "in flight", where "in flight"
>   * means that an exception has been thrown but has not been caught yet.
>   *
>   * Returns:
>   *      true when an exception is "in flight" or not.
>   */
> extern(C) bool _d_eh_isExceptionInFlight()
> ```
> 
> The function is not exposed to the outside world, but knowledgeable coders can access it using an extern(C) forward declaration.
> 
> Is this generally useful functionality and shall I upstream this to druntime? I have not looked at whether this is easy to implement for the Windows exception handling.
> If not, then I will upstream it to LDC's druntime fork.
> 
> thanks,
>    Johan
> 

That's awesome, it does belong in druntime! One change please - can you have it return the current exception as a Throwable (and null if no exception in flight)?

C++ does something similar, with a few contortions because C++ code doesn't necessarily throw objects with a common ancestor: https://en.cppreference.com/w/cpp/error/current_exception

On Tuesday, 20 October 2020 at 15:16:33 UTC, Andrei Alexandrescu wrote:
> One change please - can you have it return the current exception as a Throwable (and null if no exception in flight)?


and prolly at least document that it shouldn't let the reference escape cuz otherwise it complicates memory freeing of the exception.

basically it would be a borrowed reference. again at least just documented, not necessarily enforced, but people should be aware escaping it is UB.

On Tuesday, 20 October 2020 at 15:16:33 UTC, Andrei Alexandrescu wrote:
> On 10/20/20 10:56 AM, Johan wrote:
>> 
>> ```
>> /****************************************
>>   * Returns true when an exception is "in flight", where "in flight"
>>   * means that an exception has been thrown but has not been caught yet.
>>   *
>>   * Returns:
>>   *      true when an exception is "in flight" or not.
>>   */
>> extern(C) bool _d_eh_isExceptionInFlight()
>> ```
>
> That's awesome, it does belong in druntime! One change please - can you have it return the current exception as a Throwable (and null if no exception in flight)?
>
> C++ does something similar, with a few contortions because C++ code doesn't necessarily throw objects with a common ancestor: https://en.cppreference.com/w/cpp/error/current_exception

Actually, I made it quite intentionally _not_ return the exception, to prevent trickery by the (way too smart ;-)) Weka devs.
Note that C++'s current_exception returns the exception that has just been caught, whereas the _d_eh_isExceptionInFlight function is there to detect an exception before it was caught (returns false when in catch clause). It's been a while... I did implement something like getCurrentException, but didn't like it. Hope I can find it somewhere still.

I'll prepare something to submit to druntime soon.

cheers,
  Johan

On 10/20/20 11:23 AM, Adam D. Ruppe wrote:
> On Tuesday, 20 October 2020 at 15:16:33 UTC, Andrei Alexandrescu wrote:
>> One change please - can you have it return the current exception as a Throwable (and null if no exception in flight)?
> 
> 
> and prolly at least document that it shouldn't let the reference escape cuz otherwise it complicates memory freeing of the exception.
> 
> basically it would be a borrowed reference. again at least just documented, not necessarily enforced, but people should be aware escaping it is UB.

Nice.

extern(C) scope(Throwable) _d_eh_getExceptionInFlight();

On Tuesday, 20 October 2020 at 17:45:19 UTC, Andrei Alexandrescu wrote:
> On 10/20/20 11:23 AM, Adam D. Ruppe wrote:
>> On Tuesday, 20 October 2020 at 15:16:33 UTC, Andrei Alexandrescu wrote:
>>> One change please - can you have it return the current exception as a Throwable (and null if no exception in flight)?
>> 
>> 
>> and prolly at least document that it shouldn't let the reference escape cuz otherwise it complicates memory freeing of the exception.
>> 
>> basically it would be a borrowed reference. again at least just documented, not necessarily enforced, but people should be aware escaping it is UB.
>
> Nice.
>
> extern(C) scope(Throwable) _d_eh_getExceptionInFlight();

onlineapp.d(1): Error: declaration expected, not `(`

extern(C) scope Throwable _d_eh_getExceptionInFlight();

onlineapp.d(1): Error: function `onlineapp._d_eh_getExceptionInFlight` functions cannot be `scope`


Slightly off-topic: Unfortunately `scope` is a parameter storage class and not a type qualifier (which is probably the biggest point of contention regarding dip1000) so you can't express what you meant above.

This has certain issues:
* it makes expressing certain code patterns that should be safe impossible in @safe code (which are e.g. safe in Rust)
* it makes some holes in @safe (both language and library) hard to fix. See e.g.: https://issues.dlang.org/show_bug.cgi?id=17764
* doesn't help with concurrency safety issues, like these proposals:
  * https://forum.dlang.org/post/k831b6$1368$1@digitalmars.com
  * https://forum.dlang.org/post/kluaojijixhwigoujeip@forum.dlang.org

On Wednesday, 21 October 2020 at 06:22:28 UTC, Petar Kirov [ZombineDev] wrote:
> Slightly off-topic: Unfortunately `scope` is a parameter storage class and not a type qualifier (which is probably the biggest point of contention regarding dip1000) so you can't express what you meant above.
>
> This has certain issues:
> * it makes expressing certain code patterns that should be safe impossible in @safe code (which are e.g. safe in Rust)
> * it makes some holes in @safe (both language and library) hard to fix. See e.g.: https://issues.dlang.org/show_bug.cgi?id=17764
> * doesn't help with concurrency safety issues, like these proposals:
>   * https://forum.dlang.org/post/k831b6$1368$1@digitalmars.com
>   * https://forum.dlang.org/post/kluaojijixhwigoujeip@forum.dlang.org

Thanks for digging this up. I could really use what they describe in there.

On Wednesday, 21 October 2020 at 06:22:28 UTC, Petar Kirov [ZombineDev] wrote:
> On Tuesday, 20 October 2020 at 17:45:19 UTC, Andrei Alexandrescu wrote:
>> On 10/20/20 11:23 AM, Adam D. Ruppe wrote:
>>> On Tuesday, 20 October 2020 at 15:16:33 UTC, Andrei Alexandrescu wrote:
>>>> One change please - can you have it return the current exception as a Throwable (and null if no exception in flight)?
>>> 
>>> 
>>> and prolly at least document that it shouldn't let the reference escape cuz otherwise it complicates memory freeing of the exception.
>>> 
>>> basically it would be a borrowed reference. again at least just documented, not necessarily enforced, but people should be aware escaping it is UB.
>>
>> Nice.
>>
>> extern(C) scope(Throwable) _d_eh_getExceptionInFlight();
>
> onlineapp.d(1): Error: declaration expected, not `(`
>
> extern(C) scope Throwable _d_eh_getExceptionInFlight();
>
> onlineapp.d(1): Error: function `onlineapp._d_eh_getExceptionInFlight` functions cannot be `scope`
>
>
> Slightly off-topic: Unfortunately `scope` is a parameter storage class and not a type qualifier (which is probably the biggest point of contention regarding dip1000) so you can't express what you meant above.
>
> This has certain issues:
> * it makes expressing certain code patterns that should be safe impossible in @safe code (which are e.g. safe in Rust)
> * it makes some holes in @safe (both language and library) hard to fix. See e.g.: https://issues.dlang.org/show_bug.cgi?id=17764
> * doesn't help with concurrency safety issues, like these proposals:
>   * https://forum.dlang.org/post/k831b6$1368$1@digitalmars.com
>   * https://forum.dlang.org/post/kluaojijixhwigoujeip@forum.dlang.org

Related:
https://forum.dlang.org/thread/zayyoiupftrvbummxabk@forum.dlang.org