[
https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902806#comment-14902806
]
Matthew Pitts edited comment on ARIES-1415 at 9/22/15 3:35 PM:
---------------------------------------------------------------
I think having the exception wrapped with a custom message during TX commit is
nice for troubleshooting. I just liked the idea of maintaining the original
exception type even with a custom message by doing the reflection bit. If this
is too complicated or not intuitive, perhaps just throwing the original if it
is a RuntimeException is the best compromise.
I think there would be some recoverable exceptions that don't occur until the
TX commit is happening. OptimisticLockException is the big one that comes to
mind, but I don't know if that would show up during TX commit or from the
EmFunction body.
FYI - I did have some test cases for the AbstractJpaTemplate exception wrapping
methods that I was prototyping if you're interested.
was (Author: invinity):
I think having the exception wrapped with a custom message during TX commit is
nice for troubleshooting. I just liked the idea of maintaining the original
exception type even with a custom message by doing the reflection bit. If this
is too complicated or not intuitive, perhaps just throwing the original if it
is a RuntimeException is the best compromise.
FYI - I did have some test cases for the AbstractJpaTemplate exception wrapping
methods that I was prototyping if you're interested.
> Exception laundering in JpaTemplate impls
> -----------------------------------------
>
> Key: ARIES-1415
> URL: https://issues.apache.org/jira/browse/ARIES-1415
> Project: Aries
> Issue Type: Improvement
> Components: JPA
> Affects Versions: jpa-2.2.0
> Reporter: Matthew Pitts
> Assignee: Christian Schneider
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught
> exceptions in a new RuntimeException and throw that instead of the original.
> This can make it problematic to integrate with code that wants to run txExpr
> methods and catch specific exceptions - like NoResultException or other type
> of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class
> - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to
> instantiate a new instance of the original exception type via reflection and
> populate it with the necessary detail message. If it is unable to instantiate
> the original exception, then it can simply rethrow it as-is or maintain the
> original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
> protected RuntimeException launderTxException(Throwable original, String
> message) {
> if (RuntimeException.class.isInstance(original)) {
> return wrapTxException(RuntimeException.class.cast(original),
> message);
> }
> else {
> return new RuntimeException(message, original);
> }
> }
> protected RuntimeException wrapTxException(RuntimeException original,
> String message) {
> if (message == null)
> return original;
> try {
> RuntimeException wrapper = original.getClass().getConstructor(new
> Class[]
> { String.class }).newInstance(message);
> wrapper.initCause(original);
> return wrapper;
> }
> catch (ReflectiveOperationException e) {
> return original;
> }
> }
> {code}
> Thoughts, comments, criticisms?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
