[
https://issues.apache.org/jira/browse/DIRMINA-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615233#comment-13615233
]
Julien Vermillard commented on DIRMINA-941:
-------------------------------------------
Agreeing with Emmanuel except for that :
{code}
} catch (Throwable t) { // <<----- Here we suppose we have a pb with the
logger, and we simply dump a stackTrace
{code}
please don't catch Throwable but Exception,
Throwable not Exception are java.lang.Error : prettry serious errors like
out-of-memory or classloading stuff, you have a good chance to not being able
to log it.
Extract of java.lang.Error javadoc :
{code}
/**
* An <code>Error</code> is a subclass of <code>Throwable</code>
* that indicates serious problems that a reasonable application
* should not try to catch. Most such errors are abnormal conditions.
* The <code>ThreadDeath</code> error, though a "normal" condition,
* is also a subclass of <code>Error</code> because most applications
* should not try to catch it.
* <p>
{code}
> DefaultIoFilterChain (or any other class) should not catch Throwable without
> re-throwing
> ----------------------------------------------------------------------------------------
>
> Key: DIRMINA-941
> URL: https://issues.apache.org/jira/browse/DIRMINA-941
> Project: MINA
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0.5, 2.0.7
> Environment: N/A
> Reporter: Chris Janicki
>
> I spent several hours tracking down a bug that was ultimately caused by an
> old slf4j*-api.jar in my encompassing project's classpath. The critical
> error message ("... method not found... isTraceEnabled()...") was silenced by
> the "catch Throwable" behavior in the
> org.apache.mina.core.filterchain.DefaultIoFilterChain class. Since the
> problem was related to the logging classes, the error wasn't logged, and
> unfortunately, the runtime exception was not allowed to propagate to the
> console... Instead it was consumed in DefaultIoFilterChain. This left
> absolutely no clues for debugging why the SSH server just stopped in the
> middle of key negotiation.
> The only evidence of the problem was that the SSHD server I was embedding
> just stopped in the middle of the key exchange. In order to finally find the
> problem, I had to track down the last known working part of code in the
> ssh-core package, and edit your source code to catch and print Throwables.
> While I appreciate that this was possible because of your open source, it was
> beyond the normal programmer's expectation for embedding a library. In my
> google searches for the last printed SSH client debug state message ("debug1:
> SSH2_MSG_KEXINIT sent") , I found several people over the last few years who
> have struggled for answers at the same point in the code when using Apache's
> Mina/sshd. There's no indication that many of them succeeded in tracking
> down the problem. (I'll go back and leave some breadcrumbs for future
> travelers, where I have logins.)
> My overall point is that it's not nice to catch Throwables.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
