On Jul 11, 2011, at 10:25 AM, Emmanuel Lecharny wrote: > On 7/11/11 7:14 PM, Alan D. Cabrera wrote: >> On Jul 10, 2011, at 10:23 PM, Julien Vermillard wrote: >> >>> On Mon, Jul 11, 2011 at 1:51 AM, Alan D. Cabrera<[email protected]> >>> wrote: >>>> What would a user put as an implementation to this method? I'm wondering >>>> how useful it is. >>>> >>>> >>>> Regards, >>>> Alan >>> I use to close session on ProtocolDecoderException in >>> IoHandle#exceptionCaught. Since we removed the IoHandler and only use >>> IoFilter, I think we need this event in IoFilter. >> I was thinking that if an exception is thrown by a filter then the session >> should be closed. > > It's up to the Handler implementer to decide to close the session, or not.
Is there a concrete use case where this is necessary? If a filter barfs in such a way that it leaks an exception should not this always be treated as a critical error? > However, I think it's a good policy to default to such an action, if the > implementer hasn't overriden the event. I'm hearing a description of how general the framework is with regard to this event, not a use case that dictates this generality. >> I think this should be a hard and fast policy that is enforced by our >> framework. With that said then what we need is a lifecycle method: >> >> void processSessionHalted(IoSession session) >> >> The method processExceptionCaught() strikes me as being too vague. > Well, it's generic because you may get many kind of exception. The generality that I speak of is not the type of the exception but the fact that we simply report an exception, half expecting the listener to shut down the session. It's this vagueness in the > In some case, we can probably have another event like the one you are > proposing. However, if the session is already closed, the sessionClosed() > event will be propagated to the handler anyway.-- There's a difference between a clean shutdown of the session and a halt. I think we should make that explicit. Regards, Alan
