This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: Error message revelation
- To: Tom Tromey <tromey at redhat dot com>, Fernando Nasser <fnasser at cygnus dot com>, jingham at apple dot com
- Subject: Re: Error message revelation
- From: Keith Seitz <keiths at cygnus dot com>
- Date: Mon, 23 Apr 2001 13:04:17 -0700 (PDT)
- cc: Insight Maling List <insight at sources dot redhat dot com>
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