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
