On Sat, Jul 5, 2008 at 1:50 PM, peter royal <[EMAIL PROTECTED]> wrote:
> On Jul 3, 2008, at 9:46 AM, Emmanuel Lecharny wrote: > >> Now, the question is why do we allow a user to define it's own >> ExceptionMonitor to handle unhandled exceptions. As we are defining a >> framework, it does not make a lot of sense to disregard an exception and let >> the user define what to do with it, as the user will have _no clue_ about >> where those kind of exception might be produced (our users are not all >> supposed to go through MINA code). >> >> So do we really need this class ? IMHO, this is a bad idea which has not >> been removed from the very first version (it comes far away : the class has >> been injected back in 2005, and was never derived since, if we except the >> default implementation. >> > > This is a feature I've used in the past. > > Yes, its a very general solution, but when you want to hook into what > happens when a random exception is thrown, its a lifesaver. > > I'd be -1 on removing it. > No worries, if it helps you we should keep it. But I'm really curious though how it helped you in the past. I've used monitor callbacks instead of inline logging, then used a logging monitor implementation, to produce logging output in the past. However this often created clutter for me and not many people seemed to use it to do anything other than logging. BTW I used this monitor concept in ApacheDS years ago (4 I think) for each of it's components instead of using logging. The logging monitor implementations would produce log output instead of responding to events like exceptional conditions. I wish I could find that link to the monitors verses logging article. I encountered it after seeing a reference to it on an Avalon mailing list. Incidentally, I think this is how the influence came about on both ApacheDS and MINA. Alex
