tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Dotte (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TAP5-1963) Original exception lost in CommitAfterWorker upon abort
Date Thu, 28 Jun 2012 15:40:42 GMT

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

Ben Dotte updated TAP5-1963:
----------------------------

    Description: 
advise() in CommitAfterWorker surrounds the method invocation and session commit in a try/catch
and runs manager.abort() if a RuntimeException is caught and then rethrows the RuntimeException.
The problem is, depending on the original problem, it is not unlikely that manager.abort()
itself could throw an exception (Transaction Not Started, Transaction Already Started, etc.).
When that happens, the original RuntimeException is lost and all we get is the useless exception
generated by the call to manager.abort().

I think we should just throw away any exceptions generated by manager.abort() so that we always
retain the original RuntimeException. Something like this:

try
{
	invocation.proceed();
	// Success or checked exception:
	manager.commit();
}
catch (RuntimeException ex)
{
	try
	{
		manager.abort();
	}
	catch (Exception e)
	{
		// throw away; we want the real "ex" exception to get rethrown
	}
	throw ex;
}

  was:
advise() in CommitAfterWorker surrounds the method invocation and session commit in a try/catch
and runs manager.abort() if a RuntimeException is caught and then rethrows the RuntimeException.
The problem is, depending on the original problem, it is not unlikely that manager.abort()
itself could throw an exception (Transaction Not Started, Transaction Already Started, etc.).
When that happens, the original RuntimeException is lost and all we get is the useless exception
generated by the call to manager.abort().

I think we should just throw away any exceptions generated by manager.abort() so that we always
retain the original RuntimeException. Something like this:

{code}
try
{
	invocation.proceed();
	// Success or checked exception:
	manager.commit();
}
catch (RuntimeException ex)
{
	try
	{
		manager.abort();
	}
	catch (Exception e)
	{
		// throw away; we want the real "ex" exception to get rethrown
	}
	throw ex;
}
{code}

    
> Original exception lost in CommitAfterWorker upon abort
> -------------------------------------------------------
>
>                 Key: TAP5-1963
>                 URL: https://issues.apache.org/jira/browse/TAP5-1963
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-hibernate
>    Affects Versions: 5.3.3
>            Reporter: Ben Dotte
>            Priority: Minor
>
> advise() in CommitAfterWorker surrounds the method invocation and session commit in a
try/catch and runs manager.abort() if a RuntimeException is caught and then rethrows the RuntimeException.
The problem is, depending on the original problem, it is not unlikely that manager.abort()
itself could throw an exception (Transaction Not Started, Transaction Already Started, etc.).
When that happens, the original RuntimeException is lost and all we get is the useless exception
generated by the call to manager.abort().
> I think we should just throw away any exceptions generated by manager.abort() so that
we always retain the original RuntimeException. Something like this:
> try
> {
> 	invocation.proceed();
> 	// Success or checked exception:
> 	manager.commit();
> }
> catch (RuntimeException ex)
> {
> 	try
> 	{
> 		manager.abort();
> 	}
> 	catch (Exception e)
> 	{
> 		// throw away; we want the real "ex" exception to get rethrown
> 	}
> 	throw ex;
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message