On 6 October 2015 at 15:58, Jay McCarthy <[email protected]> wrote: > I'm not sure if this answers the question... > > These errors are coming from the Web server response-outputing code > failing when the other side closed the connection early. The exception > would not be returned to your code, because your code is a function > from "request -> response" rather than a "request -> void" function > that ends with a call to "output this response". So, the exception is > thrown on the Web server's side and will just get caught be the > connection thread's handler, which just prints it out and cleans up > for the connection.
In this scenario, I think we'd want the exception to not be printed at all, since it's entirely harmless. And it seems doing this is the job of the "Web server response-outputing code" you mention. > The only way you could grab this would be to make > a different dispatcher that called your servlet and then ran its own > "output this response" code from a context you controlled. > > In any case, what would you expect to do with such an exception? The > connection is gone and you can't do anything about it? Indeed. Since you're answering a client, nothing to do. (A client getting a reset from a server during a POST is a much more complicated matter, but thankfully we're not there). Cheers, Paolo > On Tue, Oct 6, 2015 at 9:25 AM, Tony Garnock-Jones <[email protected]> wrote: >> On 10/06/2015 12:43 AM, George Neuner wrote: >>> I don't know where to put an error handler to deal with reset conditions >>> at the end of a request. Maybe Jay has an idea? >> >> It feels like exceptions are something that response/full, >> response/xexpr and similar procedures could deal with, since they have a >> "fire and forget" flavour to them. >> >> Raw response objects wouldn't trap the exceptions, and so neither would >> response/output. >> >> The rule of thumb I have in mind is: if you're dealing with the response >> port at all, catching network exceptions is your responsibility. If the >> port is entirely hidden away from you, exception handlers would Do The >> Right Thing For You. >> >> Perhaps something like that might help the situation? >> >> Tony >> >> -- >> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > > > -- > Jay McCarthy > http://jeapostrophe.github.io > > "Wherefore, be not weary in well-doing, > for ye are laying the foundation of a great work. > And out of small things proceedeth that which is great." > - D&C 64:33 -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
