Behavior of Manage Exception Debugging window

Help!
1

I’m playing around with the Exception Debugging window as I write up the section of the docs on it. A couple follow on questions from the discussion here:

It appears that exceptions only get added to the window by default when it has been opened before the exception happens. Is this just a bug or the desired behavior?

I’m trying to keep the concept count low in the docs by describing this dialog in terms of other existing debugger features like “Trace Point” “Spy Point”. I’m curious about the term “Trace” in “Trace Not Caught” and “Trace Always”. It seems like this term is being used more descriptively than technically, meaning: this feature has nothing to do with trace mode (i.e. trace/0) and has nothing to do with trace points (i.e. trace/2). Here’s my impression of what is going on, please tell me what I got wrong:

Adding a row to the Exceptions window behaves similarly to setting a spy point on a predicate. For example, just like a spy point, if “trace always” is set for an exception and then the code throws the exception, Prolog will enter debug mode (even if it was off before) and bring up the graphical debugger [which is different from a spy point which would have used the console or graphical interface based on whether you used gtrace, etc].

After you have exited the debugger, the program will still be in debug mode. Also like a spy point, the exceptions dialog matches the exception anywhere in the code, not from a particular line where it gets thrown.

Am I right that there isn’t a command line interface, or am I missing it?

Are there predicates to enable and disable this exception trapping behavior?

2

Yes and no. The code for managing exceptions is loaded by the tool (library(trace/exceptions)) and activated by opening the tool. Once opened, the Prolog part keeps doing its work. See exception_hook/4 in the above file. I think it is good that this is not loaded by default as it can seriously reduce performance and pile up data about past exceptions.

It isn’t really a spy point on an exception. It is more like a break point. When trapped, it simply calls trace/0. As it is typically called from the GUI environment this normally results in graphical debugging, but this is not necessarily so. Unlike spy point that act on all ports of a predicate, a trapped exception simply starts the tracer. How you continue tracing, including on how you end tracing, is up to you. So, if you do l (leap), you continue in debug mode. If you do n (nodebug), you continue in normal execution mode.

Note that the mechanism doesn’t always do a good job. Notably resource exceptions may prevent the hooks and debugger from running immediately. They will run later when enough space has been reclaimed while unwinding the exception. Notably when the system was running in normal nodebug mode the interesting part of the context may have gone.

There is not. It would not be a big deal to separate the GUI from the rest of this library and provide a command line interface. Might be a good thing to do.

1 Like