One common error that happens is when a client opens a connection but
never sends a request. Eventually, that produces a timeout error, which bubbles
up to the debugger. But that's hard to reproduce. Here's an easier one, generated
by simply sending invalid output:
The FAST-HTTP.ERROR:CB-MESSAGE-COMPLETE this throws isn't catchable anywhere because the error happens in a worker thread. It has nowhere to go but the debugger. This is pretty convenient for development, but a deal-killer for production code.
The woo:run function could accept an error-handling function that the worker thread would install
with HANDLER-BIND, like this:
It turns out that you don't have to be using :num-workers to be unable to catch an error. It is also possible to be unable to catch errors in single-threaded operation.
One common error that happens is when a client opens a connection but never sends a request. Eventually, that produces a timeout error, which bubbles up to the debugger. But that's hard to reproduce. Here's an easier one, generated by simply sending invalid output:
The FAST-HTTP.ERROR:CB-MESSAGE-COMPLETE this throws isn't catchable anywhere because the error happens in a worker thread. It has nowhere to go but the debugger. This is pretty convenient for development, but a deal-killer for production code.
The
woo:run
function could accept an error-handling function that the worker thread would install with HANDLER-BIND, like this:Then, the app's error handler could invoke the
abort-worker-thread
restart to abort the worker thread, orrestart-worker
to start the worker up again.