[ 
https://issues.apache.org/jira/browse/OFBIZ-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677932#comment-13677932
 ] 

Adrian Crum commented on OFBIZ-5213:
------------------------------------

"Note that an alternative implementation of this would be to throw a checked 
exception extending from GenericEntityException so the additional catch is not 
required, but I wasn't sure which would fit better to the OFBiz way of doing 
exception handling."

This is where things get tricky. Yes, it would be nice to throw a checked 
exception, but that would change the API and require a lot of refactoring. 
(Btw, the lack of proper exception handling in the OFBiz framework is a 
constant source of frustration for me.) So, I used an unchecked exception and 
hoped that the offending client code would generate bug reports like this one.

Therefore, it would be best to fix the call site and not GenericEntity.

                
> Continue to rollback transactions after IllegalStateException
> -------------------------------------------------------------
>
>                 Key: OFBIZ-5213
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5213
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Christoph Neuroth
>         Attachments: OFBIZ-5213.patch
>
>
> Since Adrians recent changes (probably the new mutability check in 
> EntityListCache#put), we had some cases where GenericDelegator.rollback() 
> failed because one of the testOperations tries to remove a ServiceSemaphore 
> entity and fails because of the IllegalStateException thrown in 
> GenericEntity#assertIsMutable. Because this exception is not caught in the 
> rollback method, all following entities are not rolled back, which leaves the 
> database in an inconsistent state and causes failures in later tests.
> I'm attaching a patch which will continue to rollback other entities in this 
> case and report an error with the number of failed operations afterwards.
> Note that an alternative implementation of this would be to throw a checked 
> exception extending from GenericEntityException so the additional catch is 
> not required, but I wasn't sure which would fit better to the OFBiz way of 
> doing exception handling.
> The patch also includes the entity name in the exception for a bit easier 
> debugging and removes the logging from  a log-and-throw because that caused 
> the exception + stacktrace to be logged twice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to