[jira] Updated: (QPID-941) Client swallows exceptions, providing poor feedback on true source of errors.

["Marnie McCormack (JIRA)" <qp...@incubator.apache.org>]

     [ https://issues.apache.org/jira/browse/QPID-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marnie McCormack updated QPID-941:
----------------------------------

    Fix Version/s:     (was: M4)

Descoping items not being worked on for M4 into Unknown Fix Version for now

> 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
>
> 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.