One possible idiom is to use scope(failure) and take a look at the exception being thrown.

Is there a way to do that? If not, I assume it shouldn't be difficult to add to druntime?

On 6/1/21 12:36 PM, Andrei Alexandrescu wrote:
> One possible idiom is to use scope(failure) and take a look at the exception being thrown.

I've wanted that too! Only thing I think you can do is the awkward try/catch and rethrow.

> 
> Is there a way to do that? If not, I assume it shouldn't be difficult to add to druntime?

Not sure what you mean.

-Steve

On Tuesday, 1 June 2021 at 16:36:31 UTC, Andrei Alexandrescu wrote:
> One possible idiom is to use scope(failure) and take a look at the exception being thrown.
>
> Is there a way to do that? If not, I assume it shouldn't be difficult to add to druntime?

https://forum.dlang.org/thread/k6epn0$2ms6$1@digitalmars.com

On Tuesday, 1 June 2021 at 16:36:31 UTC, Andrei Alexandrescu wrote:
> One possible idiom is to use scope(failure) and take a look at the exception being thrown.
>
> Is there a way to do that? If not, I assume it shouldn't be difficult to add to druntime?

I would love this too! recently really needed that

On 6/1/21 12:46 PM, Steven Schveighoffer wrote:
> On 6/1/21 12:36 PM, Andrei Alexandrescu wrote:
>> Is there a way to do that? If not, I assume it shouldn't be difficult to add to druntime?
> 
> Not sure what you mean.

The runtime certainly has that information, so the only matter is exposing it via an API.

On 6/2/21 6:03 AM, Andrei Alexandrescu wrote:
> On 6/1/21 12:46 PM, Steven Schveighoffer wrote:
>> On 6/1/21 12:36 PM, Andrei Alexandrescu wrote:
>>> Is there a way to do that? If not, I assume it shouldn't be difficult to add to druntime?
>>
>> Not sure what you mean.
> 
> The runtime certainly has that information, so the only matter is exposing it via an API.

Yeah, OK. I thought you meant a solution could be had solely with druntime.

-Steve

On 6/2/21 6:03 AM, Andrei Alexandrescu wrote:

> The runtime certainly has that information, so the only matter is exposing it via an API.

Seems obvious for an API:

scope(failure, e) // use exception e

Could also extend to scope success

scope(success, retval) ...

Not sure scope(exit) would work, as only one of the two parameters would be valid. But then again, just do scope(success) and scope(failure) at the same time.

-Steve

On Wednesday, 2 June 2021 at 16:47:56 UTC, Steven Schveighoffer wrote:
> On 6/2/21 6:03 AM, Andrei Alexandrescu wrote:
>
>> The runtime certainly has that information, so the only matter is exposing it via an API.
>
> Seems obvious for an API:
>
> scope(failure, e) // use exception e
>
> Could also extend to scope success
>
> scope(success, retval) ...
>
> Not sure scope(exit) would work, as only one of the two parameters would be valid. But then again, just do scope(success) and scope(failure) at the same time.
>
> -Steve

+1 for scope(failure, ex)

On 6/2/21 12:47 PM, Steven Schveighoffer wrote:
> On 6/2/21 6:03 AM, Andrei Alexandrescu wrote:
> 
>> The runtime certainly has that information, so the only matter is exposing it via an API.
> 
> Seems obvious for an API:
> 
> scope(failure, e) // use exception e

I am hoping for an API that would allow picking the current exception from anywhere:

Throwable currentThrowable();

Returns null if none, or the current exception being thrown.

On Friday, 4 June 2021 at 06:02:27 UTC, Andrei Alexandrescu wrote:
> On 6/2/21 12:47 PM, Steven Schveighoffer wrote:
>> On 6/2/21 6:03 AM, Andrei Alexandrescu wrote:
>> 
>>> The runtime certainly has that information, so the only matter is exposing it via an API.
>> 
>> Seems obvious for an API:
>> 
>> scope(failure, e) // use exception e
>
> I am hoping for an API that would allow picking the current exception from anywhere:
>
> Throwable currentThrowable();
>
> Returns null if none, or the current exception being thrown.

Making exceptions a runtime feature instead of a language feature is not a good design.