mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: Is the ExceptionMonitor usefull ?
Date Sun, 06 Jul 2008 13:01:58 GMT
On Sat, Jul 5, 2008 at 1:50 PM, peter royal <proyal@apache.org> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message