Error message revelation
Keith Seitz
keiths@cygnus.com
Mon Apr 23 12:25:00 GMT 2001
Hi,
I don't know about you, but I've always wondered why I seem to get a lot
of messages like "Error:" in the console window... Here's an example:
(gdb) tk gdb_cmd "list" flubber
Error:
(gdb) tk gdb_get_breakpoint_info 12345678
Error:
The reason? When TCL_ERROR is returned by any wrapped call, IT IS ASSUMED
THAT THE ERROR MESSAGE IS IN THE INTERPRETER.
Here's the interesting bit of code in gdbtk-cmds.c (call_wrapper):
/*
* Now copy the result over to the true Tcl result. If
* GDBTK_TO_RESULT flag bit is set, this just copies a null object
* over to the Tcl result, which is fine because we should reset the
* result in this case anyway. If the wrapped command returned an
* error, then we assume that the result is already set correctly.
*/
if ((result_ptr->flags & GDBTK_IN_TCL_RESULT) || wrapped_returned_error)
{
Tcl_DecrRefCount (result_ptr->obj_ptr);
}
else
{
Tcl_SetObjResult (interp, result_ptr->obj_ptr);
}
result_ptr = old_result_ptr;
Anyone know why we only DecrRefCount when wrapped_returned_error is true?
(In other words, why are we NOT copying result_ptr->obj_ptr into the
interpreter?)
I can only guess that this was done because we want to do things like:
Tcl_WrongNumArgs (...);
return TCL_ERROR;
instead of
Tcl_WrongNumArgs (...);
result_ptr->flags &= GDBTK_IN_TCL_RESULT;
return TCL_ERROR;
However, I think that the latter, more verbose code is much easier to
remember... The result is ALWAYS taken from result_ptr->obj_ptr EXCEPT if
GDBTK_IN_TCL_RESULT is specified. That's much simpler than: result is
taken from result_ptr->obj_ptr EXCEPT if there was an error OR
GDBTK_IN_TCL_RESULT is set.
If I don't hear any objections, I am going to clean this up to make it
work. I don't want to remember a bunch of rules. Gdbtk is complex enough
as it is.
Tom?? You're name is on the change:
2000-11-29 Tom Tromey <tromey@cygnus.com>
* gdbtk-cmds.c (call_wrapper): Don't reset result if wrapped
command returned error.
Any idea what it was supposed to fix?
Keith
More information about the Insight
mailing list