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

Reply via email to