[hardeeparty]

This seems really valuable for development, but is there a way to use this in production systems? Say a user hits a bug in a CL web app. Could I write an exception handler that (1) immediately returns a 500 error page and (2) persists an image somewhere so that I could fire it up later and have the debugger ready at the offending point?

[phoe-krk]

I think that it's possible. Immediately returning a HTTP 500 is easily doable, and you should be able to fork the Lisp process, continue serving requests in the parent, and save stack information (such as function parameters, etc..) and dump the Lisp core for further analysis in the child. (Do note, however, that this process breaks all FDs, which includes open files and network sockets.)

[zeveb]

Depending on how the HTTP library works, one might be able to return an error to the user, but preserve all the other call state in an open thread, and later on join it from an interactive debugger … perhaps even a Lisp debugger running in a Web browser!

[phoe-krk]

That's doable. Common Lisp has a programmable debugger hook which allows for implementing one's own debugger - also, possibly, as a web application. And for situations where the standard debugger hook is not enough (e.g. BREAK or INVOKE-DEBUGGER), one can use https://github.com/phoe/trivial-custom-debugger to completely override the system debugger with a custom one.

[p_l]

Yes, that's actually possible. Biggest issue might be forking to dump the image and dealing with OS.

It also means you don't have to write blinks of try catch nested in while loop just to be able to retry the operation...