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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
