www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - can we get a _d_raise hook?

reply Brian Palmer <d brian.codekitchen.net> writes:
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.
Sep 25 2008
next sibling parent BCS <ao pathlink.com> writes:
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;
Sep 25 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== 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
Sep 25 2008
parent Brian Palmer <d brian.codekitchen.net> writes:
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.
Sep 25 2008