[
https://issues.apache.org/jira/browse/LANG-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved LANG-499.
-------------------------------
Resolution: Fixed
Patch applied in revision 820070.
> Add support for the handling of ExecutionExceptions
> ---------------------------------------------------
>
> Key: LANG-499
> URL: https://issues.apache.org/jira/browse/LANG-499
> Project: Commons Lang
> Issue Type: New Feature
> Reporter: Oliver Heger
> Priority: Minor
> Fix For: 3.0
>
> Attachments: ConcurrentUtils.patch
>
>
> Exceptions of the checked type {{ExecutionException}} are thrown by the Java
> 1.5 task execution framework if the execution of a task fails. Dealing with
> these exceptions is somewhat cumbersome as they wrap all kinds of possible
> error conditions: checked exceptions, runtime exceptions, and errors as well.
> Therefore in _Java Concurrency in Practice_ (JCIP) the following approach is
> suggested:
> * First inspect the root cause of the exception and check whether it is one
> of the possible checked exceptions. If this is the case, re-throw the checked
> exception (after a type cast).
> * After that call the utility method {{launderThrowable()}}.
> {{launderThrowable()}} deals with errors and runtime exceptions and throws
> them accordingly.
> This approach ensures that all possible exception types are correctly
> extracted from an {{ExecutionException}} and passed to the caller.
> This ticket is about adding support for this exception extraction process to
> _Commons Lang_.
> With regards to checked exceptions, there is probably nothing we can do to
> simplify exception handling as Java does not allow throwing arbitrary checked
> exceptions from a method. However, we could at least add a method like
> {{launderThrowable()}} to an utility class (e.g. {{ConcurrentUtils}}, which
> could provide other functionality related to the _concurrent_ package as
> well).
> We could also go a step further and define a custom Exception class, say
> {{ConcurrentException}}, which plays a similar role as
> {{ExecutionException}}, but is guaranteed to wrap only a checked exception.
> An utility method converting {{ExecutionException}} to
> {{ConcurrentException}} would - like {{launderThrowable()}} - check for
> runtime exceptions and errors and handle them directly. All other exceptions
> are wrapped in a {{ConcurrentException}}. In cases where no checked
> exceptions are needed or desired, also a runtime version
> ({{ConcurrentRuntimeException}}) could be provided.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.