On Jul 11, 2011, at 12:25 PM, Julien Vermillard wrote: > On Mon, Jul 11, 2011 at 9:04 PM, Niklas Gustavsson <[email protected]> > wrote: >> On Mon, Jul 11, 2011 at 7:43 PM, Alan D. Cabrera <[email protected]> >> wrote: >>> 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? >> >> You might at least allow the implementation to handle the error before >> closing the session. In the case of XMPP, we might want to send an >> error stanza and a closing stream stanza before the session is closed. >> >> /niklas >> > > In modbus you send an error code on corrupted message and you don't > close the session.
But wouldn't it be better if the filter that threw the exception handle the error itself? > I don't say I'm agree, but we need to be able to implement all the > know standards :) Not sure about that. Usually that kind of guiding principle creates large bloated APIs that cause confusing implementations. Sometimes the power of an API lies not in what it allows you to do but in what it does not allow you to do. I'm not sure that I've heard a use case that requires an exception escape the filter only to be returned back by the framework via an event listener with no useful context as to where the error occurred. Regards, Alan
