• Timothee Cour (14/14) Oct 25 2013 is there a way to tell whether we're running inside a try/catch block, a...
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (5/7) Oct 25 2013 Another spot is the constructor of the exception. We print the stack
• Timothee Cour (12/18) Oct 27 2013 The problem with this approach is 2-fold:

Timothee Cour <thelastmammoth gmail.com> writes:

is there a way to tell whether we're running inside a try/catch block, as
well as the type T expected by the catch(T) block (and perhaps also
file/line info) ?

use case:

i'd like to customize my exception handler so that if I'm not running in a
try/catch block, then I will pause instead of exiting so that I can start a
debugger at that point. Note that pause inside the catch block is not good,
as the stack would already be unwinded and there'd be no way to go back in
time to the point where the relevant exception got thrown. Further, I'd
like to customize this logic depending on the type expected by the catch
block.

I see relevant functions in src/druntime/src/rt/deh2.d but nothing is
exposed publicly.
thanks!

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 10/25/2013 04:12 AM, Timothee Cour wrote:

 the stack would already be unwinded and there'd be no way to go back 

in time
 to the point where the relevant exception got thrown.

Another spot is the constructor of the exception. We print the stack 
contents by libunwind in a C++ project. (Never tried in D.)

Ali

Timothee Cour <thelastmammoth gmail.com> writes:

On Fri, Oct 25, 2013 at 7:16 AM, Ali =C7ehreli <acehreli yahoo.com> wrote:

 On 10/25/2013 04:12 AM, Timothee Cour wrote:

 the stack would already be unwinded and there'd be no way to go back in

 time
 to the point where the relevant exception got thrown.

 Another spot is the constructor of the exception. We print the stack
 contents by libunwind in a C++ project. (Never tried in D.)


The problem with this approach is 2-fold:
* it requires modifying how each exception is constructed
* it doesn't know where the exception will be caught so you'd launch the
debugger at every thrown exception instead of at one location which gathers
all uncaught exceptions

I've actually worked out a solution that works great, see my post:
"proposal(+working code): catch block callback before stack unwinds to
allow attaching debugger"

it doesn't affect any try/catch blocks except the ones we specify; the key
is to put the logic as annotation at the catch block, not at the thrown
exception.