Client swallows exceptions, providing poor feedback on true source of errors.
-----------------------------------------------------------------------------
Key: QPID-941
URL: https://issues.apache.org/jira/browse/QPID-941
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: M2.1
Reporter: Marnie McCormack
Assignee: Aidan Skinner
Fix For: M3
The Java client swallows exceptions, resulting in some confusing error
reporting.
For example, no MINA jars, results in MIME type no known, as ClassNotFound
exceptions were swallowed, mime map not set up, could not find mime type when
it came to setting it. Often 'connection not tuned. error results from
missing/incorrect jars, in particular the log4j no trace issue when using log4j
< version 1.2.12, without the slf4j mapping to remap trace -> debug, shows up
as a connection not tuned error.
These error conditions would be much better served if unhandled runtime
exceptions were allowed to fall through.
There is a complication, in that sometimes the unhandled runtime will fall
through to a thread created by and private to the qpid-client library. The java
top level will print a stack trace, but the runtime will not fall into the
callers code, so they may continue running oblivious to client lib corruption.
This will still be better though, as the real exception cause will at least be
output. One solution, is to have a gloabal errorState flag for the whole
library, set whenever an unhandled exception is caught by any private thread
top-level error handler. All synchronous calls into the lib, first assert on
this global errorState, and re-throw any unhandled exceptions (probably need a
list, not just the last one) back to the caller wrapped in an
IllegalStateException.
Use IntelliJ code inspections (or equivalent on Eclipse?) to find all the
exception swallowing in the client library, and clean it up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
