On 6 October 2015 at 15:58, Jay McCarthy <jay.mccar...@gmail.com> 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 <to...@ccs.neu.edu> 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 racket-users+unsubscr...@googlegroups.com. >> 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
