On Tue, 7 Dec 1999, Ruediger zu Dohna wrote:

> Modern software is too complex to be completely tested. Many bugs will
> only show up on the customers machine. We have altered the execution
> error dialog to send us as much information as possible as an email if
> an exception occurs. But there would be more things that would help:
> 
> "the callStack" that returns the entire call chain that led to the
> current handler.

This is sort of already available: the executionError returns a
traceback of all the script elements that were executing when the
error occured.  It's more than a "call stack", though, because it
doesn't just include the function/message handler names.  Adding a
property to return just the latter information wouldn't be so bad as
long as it only had to work at error time.  There'd be a huge hit in
performance if it had to keep this info up to date at all times, and
it would be a lot of work to be able to generate it on the fly if you
had to do it without unwinding the call stack.

> "the variableNames(n)" that returns a list of all variable names used in
> the handler that is <n> frames down the call chain (the default for <n>
> is 0).
>
> "the variableScope(<name>,<n>)" that returns one of "parameter",
> "local", "script", or "global" for the variable with the name <name>
> that is <n> frames down the call chain.
> 
> "the variableValue(<name>,<n>)" that returns the value of the variable
> with the name <name> that is <n> frames down the call chain.

These three would be very difficult to add for the above reasons
unless the performance hit were acceptable, for example when running a
debugger.  Something like this is already available via the
(undocumented) "debugdo" command, which executes a "do" using the
current execution context (i.e., it's like the above but <n> is always
0).

> Even having only access to the callStack could help debugging very much.
> Who else needs this? It does not have to slow down the engine, does it?

Check out the executionError property and the scripts in the execution
error dialog and see if it does what you need.
  Regards,
    Scott

> Regards
>   R�diger
> 
> --------------------------------------------------------------------
>    GINIT - Gesellschaft fuer integrierte Informationssysteme mbH
> --------------------------------------------------------------------
> GINIT GmbH
> Ruediger zu Dohna                        email:       [EMAIL PROTECTED]
> Technologiepark                          phone:     +49-721-96681-63
> Emmy-Noether-Str. 9                      fax:       +49-721-96681-11
> D-76131 Karlsruhe                        www:    http://www.ginit.de
> --------------------------------------------------------------------
>   PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E 
> --------------------------------------------------------------------
> 

********************************************************
Scott Raney  [EMAIL PROTECTED]  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...

Reply via email to