Re: TIP #280, extended callframe introspection and debugging
- From: Fredderic <put_my_name_here@xxxxxxxxxxxxxxx>
- Date: Wed, 25 Oct 2006 19:06:34 +1000
On 24 Oct 2006 13:15:28 -0700,
"Alex" <alexandre.ferrieux@xxxxxxxxx> wrote:
On Oct 24, 8:15 pm, "Eckhard Lehmann" <eck...@xxxxxx> wrote:
A question in addition to that: is it planned or in work to have
builtin breakpoints, for stopping the execution of a script at a
certain position - or on errors?
It sure would be cool to have many bells and whistles, but I believe
your two proposals have a very different status:
1) Breaking at a certain position: it's doable today, just by
instrumenting the code, thanks to Tcl's introspective power ([info
body] et al).
Sounds like an "error hook" type job. Allow it to run before the error
begins to be propagated away. Of course, not good to be doing this
from within a [catch]... And a [catch] that re-propagates an error
will fowl it up also.
On the other hand, if it's [catch] that's installing the hook, then it
can install a function which will selectively ignore errors it's
expecting, and either fix it, or allow it to continue on... These hook
functions could stack (unlike the [catch]s which are simply layered),
allowing a general debugging level to do whatever it wants; such as
storing the current call environment, or bringing up a debugging
console.
This would NOT be the recommended means of catching errors. But it
would allow for an error console or other debugging apparatus to jump
in, inspect the state of the program, and either allow it to continue
propagating the error (after taking a look around first), halt it right
there where it stands (don't pass go, don't collect $200), or clear the
error condition and continue on as though nothing'd happened (maybe
making it possible at some stage to introduce a kind of demand-based
functionality).
Now, come to think of (2) again, one possibility would be to enrich
the "errorStack" mechanism I proposed on the wiki a few months ago,
so that the trace contains, not only the various [info level 0]
(function and args at each level), but also the [info locals]. Of
course enabling this would put a burden on the interpreter's memory
footprint, because many data would linger with a non-zero refcount
until something resets the trace list. But this would enable pretty
cool debugging tools like the one you outline.
An error has to be caught, otherwise the program explodes. So when you
catch the error, it would be your responsibility to also deal with this
extra information. Something like a -preservestate option to [error]
allowing it to rethrow all that information instead allowing the
[catch] to ground it. (There's your "something that resets the trace
list", right there.)
Hmmm... The poor [error] and [catch] commands are getting a bit of a
work-out lately... ;)
Fredderic
.
- References:
- TIP #280, extended callframe introspection and debugging
- From: Eckhard Lehmann
- Re: TIP #280, extended callframe introspection and debugging
- From: Alex
- TIP #280, extended callframe introspection and debugging
- Prev by Date: Re: Thoughts about the controversial {expand} feature
- Next by Date: Re: Itcl and TIP#257
- Previous by thread: Re: TIP #280, extended callframe introspection and debugging
- Next by thread: Re: TIP #280, extended callframe introspection and debugging
- Index(es):
Relevant Pages
|
