This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Error message revelation


On 23 Apr 2001, Tom Tromey wrote:

> When I'm writing a new Tcl command in gdbtk-cmds.c, it seems logical
> to me that it should be like writing any other random Tcl command.
> The point of call_wrapper should be, in my opinion, that the inner
> oddities of the gdb exception handling mechanism are kept from the Tcl
> code.

I could see why this would be said: it is logical. Unfortunately...

> Also, requiring a new flag to be set on every error return seemed
> redundant.  I couldn't think of a situation where you would want to
> return a TCL_ERROR but have the result text taken from some other
> source.

The problem is that we have TWO ways of returning information to the tcl 
code: the interpreter's result and result_ptr. I really think that both 
of these methods are needed in our case. The confusion comes (as you've 
noted) that there doesn't appear to be any consistent style by the rest 
of the code, so no one (including me) really knows what is supposed to be 
"the right way". (Something more for my styleguide/internals doc).

I like the explicit method: if YOU (a command writer in gdbtk) say 
GDBTK_IN_TCL_RESULT, then the result from tcl is used, otherwise, it's 
the one you've built in result_ptr->obj_ptr.

> As I recall, when looking around the code in gdbtk, there were
> numerous returns where the writer forgot to set GDBTK_IN_TCL_RESULT.

To say the least. That's what's so damn confusing. My bad, really.

> Personally I think this approach is a bug factory.  They aren't
> critical bugs, perhaps, but I'm guessing people will often forget to
> set the new flag.

I really don't think it is a bug factory, although since nothing is 
clearly documented, it actually is turning out to be one. Again, my 
fault as a maintainer (and one of the principal contributors).
 
> OTOH, a cheap-and-dirty method would be use have a new
> `RETURN_TCL_ERROR' macro that sets the flag.  Then you could find all
> the problem spots by a simple `grep "return TCL_ERROR"', both now and
> in the future.

I was thinking along these lines, but now I am beginning to wonder. Maybe 
we should just keep this assumption, change all offending code in the 
sources, and document somewhere that the rules are:

1. You're a tcl command. Behave like one.
2. You're also a gdbtk command, so you _may_ use your own output
   object (result_ptr->obj_ptr, created for you automatically) to
   optimize list creation and assembling piecemeal output from gdb.

So, then, there is a proposal: MAINTAINERS and CONTRIBUTORS: PICK ONE:

1) ALL errors come from tcl interp
   ALL output comes from tcl interp UNLESS GDBTK_IN_TCL_RESULT set
2) ALL output/errors come from result_ptr->obj_ptr UNLESS
   GDBTK_IN_TCL_RESULT is set.

Which do people prefer? I can see pros and cons for each, but I think I 
am beginning to come around to #1...

Keith


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]