Hacker News Reader

Comment by kqr | Hacker News Reader

I don't know how that would have helped. Most languages (including Python, AFAIK) unwind the stack when an exception is thrown, all the way up to the nearest catch. Whatever you wanted to do at the place of throwage is no longer possible because that stack doesn't exist other than as an incomplete printout.

In contrast, Common Lisps condition system keeps all stack between throw and catch so you can resume from anywhere in between, possibly with altered code or local variables.

Basically, Common Lisps exception stack traces are interactive by default.

View on HN

I don’t quite understand what sort of state the system is in at this stage. So the process has errored but not exited?

I know that during the exception you can pry into the variables from the stack. When do they get cleaned up?

https://stackoverflow.com/a/5328139/171450

For that to happen, you must have implemented what that SO answer says in your code. In contrast, CL allows you to modify the current running code and apply fixes.

I guess I’m confused about what running code even means after the exception. The process has crashed. Is it waiting to be reaped by a parent process?

If there is an exception a matching error handler will be selected and called in the context of the error. A default handler could be a debugger, a break loop (which is a Lisp REPL), something which asks the user waht to do or it could be a handler provided by the software, which could do anything, including looking for restarts and using one.

For example the variable a is unbound and we try to add 3.

    CL-USER 37 > (+ 3 a)

CL shows an UNBOUND-VARIABLE error and provides Restarts. Restart 3 is a USE-VALUE restart.

    Error: The variable A is unbound.
      1 (continue) Try evaluating A again.
      2 Return the value of :A instead.
      3 Specify a value to use this time instead of evaluating A.
      4 Specify a value to set A to.
      5 (abort) Return to top loop level 0.

    Type :b for backtrace or :c <option number> to proceed.
    Type :bug-form "<subject>" for a bug report template or :? for other options.

We are now in a break loop, a REPL one level deeper, in the context of the error. Let's see what the condition (-> exception) is:

    CL-USER 38 : 1 > :cc
    #<UNBOUND-VARIABLE 8010002EC3>

we call one restart (listed above, number 3) interactively, it uses the new value and continues to compute the expression. It asks for a value. I enter 5 -> 5 + 3 = 8

    CL-USER 39 : 1 > :c 3

    Enter a form to be evaluated: 5
    8

We can do it also programmatically. HANDLER-BIND establishes a handler for UNBOUND-VARIABLE. It invokes the restart USE-VALUE with 4 -> 3 + 4 = 7

    CL-USER 40 > (handler-bind ((unbound-variable #'(lambda (c)
                                                      (invoke-restart 'use-value 4))))
                   (+ 3 a))
    7

All this is the default behavior. There is no special "debug mode", attaching a debugger or "instrumentation of code" needed.

In the CL condition system they have separated error detection (exception thrown) from handler selection (catching exception) and handler implementation (what are called "restarts".)

So basically instead of registering one handler (catch block) that is responsible both for determining the proper course of action and implementing it, the condition system allows you to register multiple "restarting points" which the handler can select from when deciding how to handle the error.

One of the restarts often used in debugging is restarting any of the functions in the call chain, i.e. just trying the same thing again. But just as common is varying some parameter or local variable and then restarting the function.

The process hasn’t crashed after an exception. It still might even exit with a success error code, if you really want it to.

An exception is raised when you attempt to parse HTML as JSON. The process doesn’t end. You catch the exception, see what happened, and respond with a 400.

Ironically that stack unwinding is exactly why I like a straight old sigsegv.

Just dump the core and analyse the frozen state. One thing that annoyed me in go is that even when it core dumps on panic and after I worked on the backtrace analyser for gdb, most of the core dumps were useless as everything of worth was already unwound and lost.

Hidden in plain sight is the fact is that structured exception handling in 32-bit Windows (the linked-list-on-the-stack version[1,2], not saying anything about the gigantic-tables “zero-cost” version) is a resumable exception system a la Common Lisp conditions—inevitably, seeing as it subsumes SIGSEGV coredumps!

[1] http://bytepointer.com/resources/pietrek_crash_course_depths...

[2] http://bytepointer.com/resources/pietrek_vectored_exception_...

> Most languages (including Python, AFAIK) unwind the stack when an exception is thrown, all the way up to the nearest catch.

You might have to use a few tricks/hacks, but I'm pretty sure you can set up python in a way to breakpoint at an exception, including all local state at the throw site. Otherwise pdb would not work.

Definitely.

It’s very possible to pause (pdb-like) or persist the local state/stack.

But there needs to be an actual exception.

If someone pulls the power cord, you’re out of luck.

Can the program be recovered once the exception is thrown and you start debugging? Or is the keeping of the stack the last allowed state before exiting?

It can be caught and managed, or frozen and examined, but that branch of code has no way forward.

Reply on news.ycombinator.com