proposal(+working code): catch block callback before stack unwinds to allow attaching debugger

Timothee Cour thelastmammoth at gmail.com
Sun Oct 27 16:43:16 PDT 2013


ideal syntax would be something along those lines:

try{...}
catch(SomeThrowableType e, &callback_before_unwinding){...}
with callback_before_unwinding of type 'void function(Throwable t)'

The semantics of which is:
if 'e' is about to be caught in this particular catch block, call
callback_before_unwinding(e) _before_ unwinding stack and entering catch
block.

Advantages are:
* it allows one to, for example, attach a debugger before stack unwinds and
entering this catch block
* the debugger is only attached at that point, hence not making the regular
program slower
* it doesn't affect other catch blocks nor does it affect how
exceptions/errors are thrown
* it could even allow one to make speed up exception handling, by computing
backtrace _only_ inside this callback_before_unwinding, so that usual
exceptions (std.conv conversions etc) can be caught without any backtrace
inside the main program while unusual unintended exceptions would be caught
at the root and show proper stack trace.

This saves a lot of time when debugging issues, at _zero_ cost in
performance.

Does libunwind allow that? Otherwise could it be adapted to do that?



On Sun, Oct 27, 2013 at 6:27 AM, David Nadlinger <code at klickverbot.at>wrote:

> On Sunday, 27 October 2013 at 13:09:21 UTC, Timothee Cour wrote:
>
>> The hacky part is here:
>> in rt/deh2.d, I changed:
>>
>
> Haven't looked at the proposal in any detail yet, but keep in mind that
> rt.deh2 is only used by DMD. GDC and LDC use GCC's libunwind for exception
> handling on most platforms.
>
> If the semantics of a feature are reasonable, it's probably possible to
> implement it on top of libunwind as well, but it's definitely something to
> keep in mind.
>
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131027/614c9275/attachment-0001.html>


More information about the Digitalmars-d mailing list