Alex Karasulu wrote:
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.
Wondering how close is this to the concepts carried by AOP...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
