Return-Path: X-Original-To: apmail-aries-dev-archive@www.apache.org Delivered-To: apmail-aries-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 999FD17FB0 for ; Tue, 22 Sep 2015 13:31:04 +0000 (UTC) Received: (qmail 15460 invoked by uid 500); 22 Sep 2015 13:31:04 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 15423 invoked by uid 500); 22 Sep 2015 13:31:04 -0000 Mailing-List: contact dev-help@aries.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aries.apache.org Delivered-To: mailing list dev@aries.apache.org Received: (qmail 15209 invoked by uid 99); 22 Sep 2015 13:31:04 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Sep 2015 13:31:04 +0000 Date: Tue, 22 Sep 2015 13:31:04 +0000 (UTC) From: "Matthew Pitts (JIRA)" To: dev@aries.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (ARIES-1415) Exception laundering in JpaTemplate impls MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Matthew Pitts created ARIES-1415: ------------------------------------ Summary: 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 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 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)