[
https://issues.jboss.org/browse/SOLDER-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Mosiewicz resolved SOLDER-315.
-----------------------------------
Fix Version/s: 3.1.0.Final
Resolution: Done
I downloaded 3.1.0.Final - it seems it's corrected here.
> Seam catch eats all exceptions silently
> ---------------------------------------
>
> Key: SOLDER-315
> URL: https://issues.jboss.org/browse/SOLDER-315
> Project: Solder
> Issue Type: Bug
> Components: Exception Handling
> Affects Versions: 3.1.0.CR1
> Environment: ANY
> Reporter: Mike Mosiewicz
> Labels: catch, exception_handler, exception_handling, exceptions
> Fix For: 3.1.0.Final
>
>
> I observed that seam catch eats all exceptions silently. Specifically it make
> my development stop for a few hours becouse we didn't know there was model
> update exception. Here is what I investigated:
> 1. Every exception in CatchExceptionFilter appear to be handled (ie.
> catchEvent.isHandled() returned always true)
> 2. It was becouse it is marked handled in
> ExceptionHandlerDispatch.executeHandlers switch statement. I.e. here:
> ...
> switch (breadthFirstEvent.getFlow()) {
> case HANDLED:
> eventException.setHandled(true);
> return;
> case MARK_HANDLED:
> eventException.setHandled(true);
> <<<<<<<<<<<<<<<<<<
> ....
> 3. breadthFirstEvent.getFlow() is MARK_HANDLED becouse it's the default value.
> The result is that it's enough there is a matching exception handler to mark
> the caught exception as handled and stop any exception display. And it's
> highly probable that you have seam-transaction in your library, so you have
> org.jboss.seam.transaction.SimpleTransactionExceptionHandler.markTransactionRollback
> handler active. That handler is intended to mark all the exceptional
> transactions to roll back. However it is irrelevant for this handler what
> kind of exception it handles. I wouldn't say that it actually handles
> exceptions. It just wants to know of all the exception that may cause
> transaction to be invalid and to rollback the transaction. But it definitely
> should be no mean to stop further processing of exception and it was probably
> not intended to hide exceptions.
> I think there should be (at least) two kind of handlers. Those that just
> listen to exceptions and do some actions but they are not supposed to be a
> final destination for exceptions. These could be transaction related
> handlers, logging handlers, etc. And there should also be handlers that are
> able to deal with specific exceptions ultimately.
> Right now there is a notion that exception is handled if there is a handler
> for the exception. If so - SimpleTransactionExceptionHandler should not be a
> handler.
> I think it would be better if MARK_HANDLED was renamed to UNHANDLED and
> wouldn't cause eventException.setHandled(true). I would then use some
> annotation to add to those handler that are ultimate and definite, or set
> handled property programatically. The whole difference between HANDLED and
> MARK_HANDLED states is artificial. It feels like there should be a difference
> when some handler says that it really handled the situation or did not.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
seam-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-issues
