On 10/6/2015 5:43 PM, Tony Garnock-Jones wrote:
On 10/06/2015 03:12 PM, George Neuner wrote:
> My (maybe wrong) understanding is that the response/* functions only
> package the response data for the send/* functions to transmit.
They construct a `response` struct which includes an `output` procedure
which, given a port, is to write the response body to it.
So one might catch the exceptions in that procedure.
The /xexpr and /full variations have a precomputed blob to send, ready
in advance of the procedure being called, so the closure they build
could swallow TCP exceptions; the more general routines take an `output`
procedure directly.
I wasn't really aware of the internals, but I should have remembered
about the generic functions because I'm wrapping response/output to
write JSON and set cookies.
> However the send/* functions terminate the handler thread (possibly
> with a saved continuation), so we're back to "where does the error
> handler need to be?"
I think those functions end up passing the results of the response/*
functions out past the servlet-prompt; the `response-output` procedure
is called as usual to generate the response body.
That sounds reasonable. I'll have to try it.
I'm not the OP, and in the case of a web-server app I agree with Jay
that there's little can be done if a send fails [perhaps better
application specific logging instead of the generic error]. If it does
allow catching send errors it could prove useful at some point.
Thanks for the explanation.
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
