On Tue, Jul 12, 2011 at 4:33 PM, Alan D. Cabrera <[email protected]> wrote: > > On Jul 12, 2011, at 12:55 AM, Julien Vermillard wrote: > >> On Mon, Jul 11, 2011 at 10:18 PM, Niklas Gustavsson >> <[email protected]> wrote: >>> On Mon, Jul 11, 2011 at 9:34 PM, Alan D. Cabrera <[email protected]> >>> wrote: >>>> That makes sense but wouldn't the implementation of IoFilter catch the >>>> exception and do the required task within the context of the error? Why >>>> let the exception fly out and be caught by the external framework only to >>>> be sent in via an event handler with no relevant context? >>> >>> Currently, we use this in both FtpServer and Vysper to handler >>> exceptions thrown during the codec, which is done in a filter that we >>> reuse and thus do not manage directly. Of course, we could probably >>> subclass the filter and handle it in our subclass. Not sure what's >>> simplest. >>> >>> /niklas >>> >> >> I agree this exception event processing is ugly, but the behaviour in >> case of decoding error is to be handled at the logical layer and not >> in the parser layer. >> >> Well let's try to work out another solution :) an Exception >> listener/handler for a given chain ? to be implemented by the last >> Filter or some business logic ? > > I don't understand why we have to add more classes and logic for what should > be a simple policy, filters should not throw exceptions unless it's a fatal > error. When that occurs the session halts. > >> I really would like to kick-out this chain of exception caught event. >> >> Julien > >
Ok I'm convinced I'll give it a try :)
