[ruby-core:36474] Error reporting, backtraces and the debugger

Dear people,

I have a passion for solid error reporting, both for end-users and to  
assist debugging.
I find Ruby to be a little lacking in some areas, and I'd like to help  
improve it.

Because this is a big topic, I'd like to discuss it here before  
opening issues on Redmine.

HISTORY

(1) http://redmine.ruby-lang.org/issues/839 by Roger Pack

This issue requested exception backtraces that contain the text of the  
source code line for each backtrace level.

Nobuyoshi Nakada offered a patch that turns each backtrace entry into  
a Struct with to_str and inspect that return the existing (textual)  
format. The patch uses SCRIPT_LINES to return the source code text, if  
that has been populated.

Roger also asked that method parameters should also be included in  
each entry.

(2) http://redmine.ruby-lang.org/issues/1906 by Run Paint Run Run

This issue requested that "caller" should be replaced (or augmented)  
by a new method "backtrace" which yields an object-oriented backtrace.

It did not request that the same change be made to  
Exception#backtrace, although the same name is suggested. (I find this  
ommision strange).

Yehuda Katz mentions that Rubinius has an objectified backtrace.

PROPOSALS

In addition to the previous two excellent suggestions, I'd like to ask  
for these to be discussed. I'm willing to be part of a coordinated  
approach to these proposals, of course:

(3) Adding the method-call binding to each exception entry (like rbx'  
MethodContext)

This would allow the debugger to access and display local variables  
from the call stack.

(4) Providing a debugger hook that can be called when an exception  
object is *about* to be thrown, but before it actually is thrown. This  
way it's easier to discover the reason an exception is being thrown,  
because the call stack which led to it still exists.

(5) That a documentation person or team scrutinises the text of every  
exception thrown in the Ruby core, and ensures that each message  
provides all possible context about the nature of the error. For  
example, "No such file or directory" should at least contain the  
filename which caused the error.

(6) Providing a debugger capability to step "into" a method which is  
being passed a block. This is between "step over" and "step in"  
because it doesn't step into the method, but will stop on the first  
line of the passed block (if the method yields, otherwise it's like  
"step over"). This would be especially useful for nested trace blocks  
(trace "foo" { ... }) where you always want to step into the block and  
never into the trace method itself.

That's it for now. I don't ask for much, do I? :) I'd value your  
thoughts...

Clifford Heath.