Want a Debug Hook?

This article is for those REBOLers who want more control over debugging, for IDEs, etc. Do you want a debug hook into the error throw mechanism?

What is it? In R2, when an error happens, the stack is thrown immediately back to a prior predetermined interpreter state and all the state between the error and the catch are discarded. So, there's no way to examine the arguments of the current function, see a backtrace list of functions, etc.

In R3 we can add a debug hook that lets you trap the internal error handler, delaying the throw, and allowing special code to access the interpreter's stack. (Note that this is nothing unusual in most interpreters. In fact, what is unusual is that we've gone this far with REBOL not providing it.)

The stack holds the function context, function arg frame, function word reference (for named functions or pathed functions), the prior frame reference (for unwinding), and computation temporaries. These are all valid REBOL datatypes, so you could in theory access the stack like a block itself. So, a debugging IDE could display all the relevant info, as most programmers would want to see during debug sessions.

Of course, we must also be careful to keep access to this information well abstracted to avoid future compatibility issues, should we want to extend the stack format. That is a big concern we need to address. In addition, we will want to be careful in error cases that put the stack into a questionable state, such as "not enough memory" or "corruption" types of errors ("should not happen").

Note: I should add that there could be some run-time security issues related to such debug hooks (such as searching back the stack for encryption keys, etc.), so this feature may require that the secure function specify that debugging is enabled for debugging sessions. It is too early to know the precise details here, but security is of high priority.

16 Comments