Thread overview
can we get a _d_raise hook?
Sep 25, 2008
Brian Palmer
Sep 25, 2008
BCS
Sep 25, 2008
Sean Kelly
Sep 25, 2008
Brian Palmer
September 25, 2008
I wrote a simple D 2.0 library using the backtrace functions (http://www.kernel.org/doc/man-pages/online/pages/man3/backtrace.3.html) and std.demangle to return an array of structs representing a stack trace.

However it's of limited use right now for debugging exceptions since I can only use it with exceptions that I define myself. Walter, can we get a hook into _d_raise so that we can execute an arbitrary function every time an exception is raised? I'm thinking along the lines of the GNU C hooks for malloc (http://www.gnu.org/software/libtool/manual/libc/Hooks-for-Malloc.html)

What do others think about this? I imagine there would be a tiny performance hit even if no hook is defined, since _d_raise will have to check for the hook on each raise. It's in the exception codepath, though, so the performance hit doesn't seem like an issue to me. The other issue is what happens if the hook itself raises an exception -- seems like aborting the process is the only real solution.

If others like the idea, I'll open a ticket in bugzilla.
September 25, 2008
Reply to Brian,

> I wrote a simple D 2.0 library using the backtrace functions
> (http://www.kernel.org/doc/man-pages/online/pages/man3/backtrace.3.htm
> l) and std.demangle to return an array of structs representing a stack
> trace.
> 
> However it's of limited use right now for debugging exceptions since I
> can only use it with exceptions that I define myself. Walter, can we
> get a hook into _d_raise so that we can execute an arbitrary function
> every time an exception is raised? I'm thinking along the lines of the
> GNU C hooks for malloc
> (http://www.gnu.org/software/libtool/manual/libc/Hooks-for-Malloc.html
> )
> 
> What do others think about this? I imagine there would be a tiny
> performance hit even if no hook is defined, since _d_raise will have
> to check for the hook on each raise. It's in the exception codepath,
> though, so the performance hit doesn't seem like an issue to me. The
> other issue is what happens if the hook itself raises an exception --
> seems like aborting the process is the only real solution.
> 
> If others like the idea, I'll open a ticket in bugzilla.
> 

vote += 1;


September 25, 2008
== Quote from Brian Palmer (d@brian.codekitchen.net)'s article
> I wrote a simple D 2.0 library using the backtrace functions (http://www.kernel.org/doc/man-
pages/online/pages/man3/backtrace.3.html) and std.demangle to return an array of structs representing a stack trace.
> However it's of limited use right now for debugging exceptions since I can only use it with exceptions
that I define myself. Walter, can we get a hook into _d_raise so that we can execute an arbitrary function every time an exception is raised? I'm thinking along the lines of the GNU C hooks for malloc (http://www.gnu.org/software/libtool/manual/libc/Hooks-for-Malloc.html)
> What do others think about this? I imagine there would be a tiny performance hit even if no hook is
defined, since _d_raise will have to check for the hook on each raise. It's in the exception codepath, though, so the performance hit doesn't seem like an issue to me. The other issue is what happens if the hook itself raises an exception -- seems like aborting the process is the only real solution.

I feel like a broken record sometimes for saying so, but "this feature is already in Tango."
More constructively, if we end up with a common runtime then it will be available in
Phobos as well.


Sean
September 25, 2008
Sean Kelly Wrote:

> I feel like a broken record sometimes for saying so, but "this feature is already in Tango."
> More constructively, if we end up with a common runtime then it will be available in
> Phobos as well.

I don't use Tango, so I looked this up in the API and Runtime.traceHandler is indeed exactly what I'm asking to be added to Phobos. I've still got my fingers crossed that we do end up with a common runtime sooner rather than later. My proposal still stands though, as I'd like to see this added to Phobos independently of what happens in the long term.