Thread overview
how to tell whether we are running inside a try/catch block?
Oct 25, 2013
Timothee Cour
Oct 25, 2013
Ali Çehreli
Oct 27, 2013
Timothee Cour
October 25, 2013
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!


October 25, 2013
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

October 27, 2013
On Fri, Oct 25, 2013 at 7:16 AM, Ali Çehreli <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.