On Thu, 2006-10-19 at 14:20 -0400, Sam Berlin wrote: > > I think it is pointless to expect a high level protocol handler to be > > able to recover from runtime exceptions and IOException and > > HttpException are the only two types of checked exceptions that can be > > thrown. Anyways, I can live with it either way. > > I'm not sure if I interpreted this correctly, but the thread that > manages the selector must be prepared to handle all kinds of > exceptions (Throwables & RuntimeExceptions included), otherwise any > stray error would halt all I/O processing. I suggest having some kind > of callback to inform the user of an arbitrary exception. Normally I > would be a staunch advocate for letting any exception propogate as far > up the stack as possible, but when the entire I/O subsystem can be > halted as a result of any error, I think it's worthwhile to disregard > that rule and catch any error. > > Sam >
Sam, et al I believe the situation should be looked at from a somewhat different angle. I still think it makes no sense to propagate runtime exceptions from the I/O thread to individual handlers, whereas safeguards must be in place to ensure that a stray runtime exception thrown by a protocol handler cannot take down the whole I/O reactor by killing its thread. Oleg > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
