Re: Is the ExceptionMonitor usefull ?
On Sat, Jul 12, 2008 at 9:12 PM, peter royal <[EMAIL PROTECTED]> wrote:
> On Jul 7, 2008, at 2:30 PM, Niklas Gustavsson wrote:
>>
>>@Override
>>public void exceptionCaught(Throwable cause) {
>> -if (log.isWarnEnabled()) {
>> +if (cause instanceof Error) {
>> +throw (Error) cause;
>> +} else {
>>log.warn("Unexpected exception.", cause);
>>}
>
> +1
Applied.
$ svn -m "Making sure the DefaultExceptionMonitor does not catch and
swallow Errors, such as OOM" commit
src/main/java/org/apache/mina/core/DefaultExceptionMonitor.java
Sendingsrc/main/java/org/apache/mina/core/DefaultExceptionMonitor.java
Transmitting file data .
Committed revision 676293.
/niklas
Re: Is the ExceptionMonitor usefull ?
On Jul 7, 2008, at 2:30 PM, Niklas Gustavsson wrote:
@Override
public void exceptionCaught(Throwable cause) {
-if (log.isWarnEnabled()) {
+if (cause instanceof Error) {
+throw (Error) cause;
+} else {
log.warn("Unexpected exception.", cause);
}
+1
-pete
--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi
smime.p7s
Description: S/MIME cryptographic signature
Re: Is the ExceptionMonitor usefull ?
Mark Webb wrote: one additional note I have is that maybe it should be moved from core to util. That way the package name indicates that it is a utility class and not a core class. Good point ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Is the ExceptionMonitor usefull ?
one additional note I have is that maybe it should be moved from core to util. That way the package name indicates that it is a utility class and not a core class. On Mon, Jul 7, 2008 at 7:23 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Mark Webb wrote: > >> +1. Its not hurting anything being there, and unless you know what its >> for, >> you will probably not use it. >> >> > > Funny :) I guess that now that I have posted the first mail, there are more > people aware about this class than ever, and now the risk is that we may > have to deal with it, as some may want to implement an inherited class, when > remaining silent and saying nothing about it would have let this class > hidden and unused forever ;) > > Sometime it's better to push the dust under the carpet and shut up :) > > Ok, I'm done with MonitorException, moving to some more useful things ! > > Thanks guys ! > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
Re: Is the ExceptionMonitor usefull ?
Mark Webb wrote: +1. Its not hurting anything being there, and unless you know what its for, you will probably not use it. Funny :) I guess that now that I have posted the first mail, there are more people aware about this class than ever, and now the risk is that we may have to deal with it, as some may want to implement an inherited class, when remaining silent and saying nothing about it would have let this class hidden and unused forever ;) Sometime it's better to push the dust under the carpet and shut up :) Ok, I'm done with MonitorException, moving to some more useful things ! Thanks guys ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Is the ExceptionMonitor usefull ?
On Mon, Jul 7, 2008 at 9:43 PM, Adam Fisk <[EMAIL PROTECTED]> wrote:
> That said, it's most importantly not a big issue and should be barely
> visible on the priority list. Getting 2.0 out the door should be the
> overarching focus of MINA right now, and things like this distract
> from that. I know it's always tempting to tweak code to one's liking
> as you make your way through it, but it's an important temptation to
> resist!
While I wholeheartedly agree, I think the issue that Emmanuel brought
up with the ExceptionMonitor catching also Errors should be corrected.
How about making the following change:
Index: core/src/main/java/org/apache/mina/core/DefaultExceptionMonitor.java
===
--- core/src/main/java/org/apache/mina/core/DefaultExceptionMonitor.java
(revision
674647)
+++ core/src/main/java/org/apache/mina/core/DefaultExceptionMonitor.java
(working
copy)
@@ -39,7 +39,9 @@
@Override
public void exceptionCaught(Throwable cause) {
-if (log.isWarnEnabled()) {
+if (cause instanceof Error) {
+throw (Error) cause;
+} else {
log.warn("Unexpected exception.", cause);
}
}
/niklas
Re: Is the ExceptionMonitor usefull ?
+1. Its not hurting anything being there, and unless you know what its for, you will probably not use it. On Mon, Jul 7, 2008 at 3:43 PM, Adam Fisk <[EMAIL PROTECTED]> wrote: > I'd just like to chime in with a vote for staying focused. If this is > not causing problems for people and people are using it, it should > stay, so I'm also a -1 on making the change. > > That said, it's most importantly not a big issue and should be barely > visible on the priority list. Getting 2.0 out the door should be the > overarching focus of MINA right now, and things like this distract > from that. I know it's always tempting to tweak code to one's liking > as you make your way through it, but it's an important temptation to > resist! > > All the Best, > -Adam > > > On Mon, Jul 7, 2008 at 1:30 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> > wrote: > > peter royal wrote: > >> > >> On Jul 5, 2008, at 1:36 PM, Emmanuel Lecharny wrote: > >>> > >>> - as it's a framework, I think that exceptions, if they are to be > >>> caught, should be caught at the upper level, not down in the code. Why > >>> the hell do we have to define a generic monitor which does nothing > >>> more than logging a warning ? > >>> > >>> I don't really care to keep it into the code base, I just don't see > >>> any of the advantages it brings. I may miss something ... > >>> > >>> Can you give me a clear exemple, Peter ? > >> > >> the monitor would allow a user to replace the functionality with one > that > >> throws rather than logs.. we just decided that logging is the best > policy. > >> we could just make it throw. > >> > >> in the custom implementation i last used, > >> > >> - if the exception is an InterruptedException, just ignore, but set the > >> interrupted state on the current thread > >> - certain exception types were ignored, no logging. > >> - certain exceptions were logged at debug > >> - catch-all was similar to what we ship > > > > I see where you are going to. The problem to me is that the current > > implementation is really not good. First it's not documented correctly, > or > > should I say, advertized, so the user have no clue what he will get if he > > implements the Monitor, second, it's a singleton, a very bad thing in a > J2EE > > environment. > > > > And as MINA is a framework, I also think that it should always throw an > > exception, and log something. Simply logging is not, IMO, enough. In > certain > > cases, we don't know what will happen if we use the default > implementation. > > For instance, you may swallow a OOM exception without doing nothing but > > logging. Do you think it's a good way to handle such exceptions ? > >> > >> .. but the specifics of how i used it aside.. > > > > I agree. > >> > >> i think the idea that it promotes is fine. > > > > Well, I'm not on the same line :) > >> > >> its not a piece of the codebase that's been causing issues at all :) > > > > That, I agree. I just don't like the idea of ExceptionMonitor, at least > the > > way it is used in MINA. It's pretty much a thread likely to be dead soon, > as > > I don't want to argue forever about a very side element of the project. > Just > > wanted to point out an opinion, but don't want to push it to a point we > have > > to get a veto from someone :) As far as we get this piece of code > > self-explanatory in the Javadoc, it's fine... > > > > Thanks Peter ! > > > > -- > > -- > > cordialement, regards, > > Emmanuel Lécharny > > www.iktek.com > > directory.apache.org > > > > > > > > > > -- > http://www.littleshoot.org > Open Source, Open Standards, Open Data >
Re: Is the ExceptionMonitor usefull ?
On Mon, Jul 7, 2008 at 3:43 PM, Adam Fisk <[EMAIL PROTECTED]> wrote: > I'd just like to chime in with a vote for staying focused. If this is > not causing problems for people and people are using it, it should > stay, so I'm also a -1 on making the change. > > That said, it's most importantly not a big issue and should be barely > visible on the priority list. Getting 2.0 out the door should be the > overarching focus of MINA right now, and things like this distract > from that. I know it's always tempting to tweak code to one's liking > as you make your way through it, but it's an important temptation to > resist! > That was really well put. Let's just move on. Alex > > > On Mon, Jul 7, 2008 at 1:30 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> > wrote: > > peter royal wrote: > >> > >> On Jul 5, 2008, at 1:36 PM, Emmanuel Lecharny wrote: > >>> > >>> - as it's a framework, I think that exceptions, if they are to be > >>> caught, should be caught at the upper level, not down in the code. Why > >>> the hell do we have to define a generic monitor which does nothing > >>> more than logging a warning ? > >>> > >>> I don't really care to keep it into the code base, I just don't see > >>> any of the advantages it brings. I may miss something ... > >>> > >>> Can you give me a clear exemple, Peter ? > >> > >> the monitor would allow a user to replace the functionality with one > that > >> throws rather than logs.. we just decided that logging is the best > policy. > >> we could just make it throw. > >> > >> in the custom implementation i last used, > >> > >> - if the exception is an InterruptedException, just ignore, but set the > >> interrupted state on the current thread > >> - certain exception types were ignored, no logging. > >> - certain exceptions were logged at debug > >> - catch-all was similar to what we ship > > > > I see where you are going to. The problem to me is that the current > > implementation is really not good. First it's not documented correctly, > or > > should I say, advertized, so the user have no clue what he will get if he > > implements the Monitor, second, it's a singleton, a very bad thing in a > J2EE > > environment. > > > > And as MINA is a framework, I also think that it should always throw an > > exception, and log something. Simply logging is not, IMO, enough. In > certain > > cases, we don't know what will happen if we use the default > implementation. > > For instance, you may swallow a OOM exception without doing nothing but > > logging. Do you think it's a good way to handle such exceptions ? > >> > >> .. but the specifics of how i used it aside.. > > > > I agree. > >> > >> i think the idea that it promotes is fine. > > > > Well, I'm not on the same line :) > >> > >> its not a piece of the codebase that's been causing issues at all :) > > > > That, I agree. I just don't like the idea of ExceptionMonitor, at least > the > > way it is used in MINA. It's pretty much a thread likely to be dead soon, > as > > I don't want to argue forever about a very side element of the project. > Just > > wanted to point out an opinion, but don't want to push it to a point we > have > > to get a veto from someone :) As far as we get this piece of code > > self-explanatory in the Javadoc, it's fine... > > > > Thanks Peter ! > > > > -- > > -- > > cordialement, regards, > > Emmanuel Lécharny > > www.iktek.com > > directory.apache.org > > > > > > > > > > > -- > http://www.littleshoot.org > Open Source, Open Standards, Open Data >
Re: Is the ExceptionMonitor usefull ?
I'd just like to chime in with a vote for staying focused. If this is not causing problems for people and people are using it, it should stay, so I'm also a -1 on making the change. That said, it's most importantly not a big issue and should be barely visible on the priority list. Getting 2.0 out the door should be the overarching focus of MINA right now, and things like this distract from that. I know it's always tempting to tweak code to one's liking as you make your way through it, but it's an important temptation to resist! All the Best, -Adam On Mon, Jul 7, 2008 at 1:30 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > peter royal wrote: >> >> On Jul 5, 2008, at 1:36 PM, Emmanuel Lecharny wrote: >>> >>> - as it's a framework, I think that exceptions, if they are to be >>> caught, should be caught at the upper level, not down in the code. Why >>> the hell do we have to define a generic monitor which does nothing >>> more than logging a warning ? >>> >>> I don't really care to keep it into the code base, I just don't see >>> any of the advantages it brings. I may miss something ... >>> >>> Can you give me a clear exemple, Peter ? >> >> the monitor would allow a user to replace the functionality with one that >> throws rather than logs.. we just decided that logging is the best policy. >> we could just make it throw. >> >> in the custom implementation i last used, >> >> - if the exception is an InterruptedException, just ignore, but set the >> interrupted state on the current thread >> - certain exception types were ignored, no logging. >> - certain exceptions were logged at debug >> - catch-all was similar to what we ship > > I see where you are going to. The problem to me is that the current > implementation is really not good. First it's not documented correctly, or > should I say, advertized, so the user have no clue what he will get if he > implements the Monitor, second, it's a singleton, a very bad thing in a J2EE > environment. > > And as MINA is a framework, I also think that it should always throw an > exception, and log something. Simply logging is not, IMO, enough. In certain > cases, we don't know what will happen if we use the default implementation. > For instance, you may swallow a OOM exception without doing nothing but > logging. Do you think it's a good way to handle such exceptions ? >> >> .. but the specifics of how i used it aside.. > > I agree. >> >> i think the idea that it promotes is fine. > > Well, I'm not on the same line :) >> >> its not a piece of the codebase that's been causing issues at all :) > > That, I agree. I just don't like the idea of ExceptionMonitor, at least the > way it is used in MINA. It's pretty much a thread likely to be dead soon, as > I don't want to argue forever about a very side element of the project. Just > wanted to point out an opinion, but don't want to push it to a point we have > to get a veto from someone :) As far as we get this piece of code > self-explanatory in the Javadoc, it's fine... > > Thanks Peter ! > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > > -- http://www.littleshoot.org Open Source, Open Standards, Open Data
Re: Is the ExceptionMonitor usefull ?
peter royal wrote: On Jul 5, 2008, at 1:36 PM, Emmanuel Lecharny wrote: - as it's a framework, I think that exceptions, if they are to be caught, should be caught at the upper level, not down in the code. Why the hell do we have to define a generic monitor which does nothing more than logging a warning ? I don't really care to keep it into the code base, I just don't see any of the advantages it brings. I may miss something ... Can you give me a clear exemple, Peter ? the monitor would allow a user to replace the functionality with one that throws rather than logs.. we just decided that logging is the best policy. we could just make it throw. in the custom implementation i last used, - if the exception is an InterruptedException, just ignore, but set the interrupted state on the current thread - certain exception types were ignored, no logging. - certain exceptions were logged at debug - catch-all was similar to what we ship I see where you are going to. The problem to me is that the current implementation is really not good. First it's not documented correctly, or should I say, advertized, so the user have no clue what he will get if he implements the Monitor, second, it's a singleton, a very bad thing in a J2EE environment. And as MINA is a framework, I also think that it should always throw an exception, and log something. Simply logging is not, IMO, enough. In certain cases, we don't know what will happen if we use the default implementation. For instance, you may swallow a OOM exception without doing nothing but logging. Do you think it's a good way to handle such exceptions ? .. but the specifics of how i used it aside.. I agree. i think the idea that it promotes is fine. Well, I'm not on the same line :) its not a piece of the codebase that's been causing issues at all :) That, I agree. I just don't like the idea of ExceptionMonitor, at least the way it is used in MINA. It's pretty much a thread likely to be dead soon, as I don't want to argue forever about a very side element of the project. Just wanted to point out an opinion, but don't want to push it to a point we have to get a veto from someone :) As far as we get this piece of code self-explanatory in the Javadoc, it's fine... Thanks Peter ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Is the ExceptionMonitor usefull ?
On Jul 5, 2008, at 1:36 PM, Emmanuel Lecharny wrote: - as it's a framework, I think that exceptions, if they are to be caught, should be caught at the upper level, not down in the code. Why the hell do we have to define a generic monitor which does nothing more than logging a warning ? I don't really care to keep it into the code base, I just don't see any of the advantages it brings. I may miss something ... Can you give me a clear exemple, Peter ? the monitor would allow a user to replace the functionality with one that throws rather than logs.. we just decided that logging is the best policy. we could just make it throw. in the custom implementation i last used, - if the exception is an InterruptedException, just ignore, but set the interrupted state on the current thread - certain exception types were ignored, no logging. - certain exceptions were logged at debug - catch-all was similar to what we ship .. but the specifics of how i used it aside.. i think the idea that it promotes is fine. its not a piece of the codebase that's been causing issues at all :) -pete -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
Re: Is the ExceptionMonitor usefull ?
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
Re: Is the ExceptionMonitor usefull ?
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
Re: Is the ExceptionMonitor usefull ?
> 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. the big problems I see with the implemented somultion are : - documentation is really misleading. In fact, it's a complete non sense. - either you use runtime exceptions, or not. In the second case, you should anyway catch them, so the solution is useless. In the former case, I don't see why you should catch a runtime exception - as it's a framework, I think that exceptions, if they are to be caught, should be caught at the upper level, not down in the code. Why the hell do we have to define a generic monitor which does nothing more than logging a warning ? I don't really care to keep it into the code base, I just don't see any of the advantages it brings. I may miss something ... Can you give me a clear exemple, Peter ? Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Is the ExceptionMonitor usefull ?
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. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
Re: Is the ExceptionMonitor usefull ?
I think this was something Trustin and I talked about while experimenting
with Monitors verses logging. This was from some concepts that Paul Hammant
was expounding via Pico Container. It was a bad idea then and I think it is
a bad idea now. Not bad rather but just worthless Thoughtworks
masterbation.
Alex
On Thu, Jul 3, 2008 at 12:46 PM, Emmanuel Lecharny <[EMAIL PROTECTED]>
wrote:
> Hi guys,
>
> I'm currently spending some time documenting the AbstractIoService class,
> where the ExceptionMonitor instance is created. This class is just used to
> handle exception when they are uncaught :
>
> /**
> * Monitors uncaught exceptions. [EMAIL PROTECTED]
> #exceptionCaught(Throwable)} is
> * invoked when there are any uncaught exceptions.
> */
> public abstract class ExceptionMonitor {
> ...
>
>
> At least, this is what the Javadoc says ... But in fact, 'uncaught
> exception' does not make a lot of sense. Either we catch an exception, or
> not. If we don't catch it, there is no way to deal with it as an uncaught
> exception, because otherwise, it means it has been caught, and is not
> anymore uncaught ... :/
>
> There is soemthing wrong in this logic. All over the code, we see things
> like :
>
> try {
> ...
> } catch (Throwable t) {
> ExceptionMonitor.getInstance().exceptionCaught(t);
> }
>
> Assuming that we are using the DefaultExceptionMonitor, this will simply
> log a warning in some log :
>
> public class DefaultExceptionMonitor extends ExceptionMonitor {
> private final Logger log =
> LoggerFactory.getLogger(DefaultExceptionMonitor.class);
>
> public void exceptionCaught(Throwable cause) {
> if (log.isWarnEnabled()) {
> log.warn("Unexpected exception.", cause);
> }
> }
>
> Why don't we simply write :
> try {
> ...
> } catch (Throwable t) {
> log.warn("Unexpected exception.", t);
> }
>
> ?
>
> 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.
>
> wdyt ?
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Is the ExceptionMonitor usefull ?
Hi guys,
I'm currently spending some time documenting the AbstractIoService
class, where the ExceptionMonitor instance is created. This class is
just used to handle exception when they are uncaught :
/**
* Monitors uncaught exceptions. [EMAIL PROTECTED] #exceptionCaught(Throwable)}
is
* invoked when there are any uncaught exceptions.
*/
public abstract class ExceptionMonitor {
...
At least, this is what the Javadoc says ... But in fact, 'uncaught
exception' does not make a lot of sense. Either we catch an exception,
or not. If we don't catch it, there is no way to deal with it as an
uncaught exception, because otherwise, it means it has been caught, and
is not anymore uncaught ... :/
There is soemthing wrong in this logic. All over the code, we see things
like :
try {
...
} catch (Throwable t) {
ExceptionMonitor.getInstance().exceptionCaught(t);
}
Assuming that we are using the DefaultExceptionMonitor, this will simply
log a warning in some log :
public class DefaultExceptionMonitor extends ExceptionMonitor {
private final Logger log =
LoggerFactory.getLogger(DefaultExceptionMonitor.class);
public void exceptionCaught(Throwable cause) {
if (log.isWarnEnabled()) {
log.warn("Unexpected exception.", cause);
}
}
Why don't we simply write :
try {
...
} catch (Throwable t) {
log.warn("Unexpected exception.", t);
}
?
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.
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
