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

ASF subversion and git services commented on ISIS-665:
------------------------------------------------------

Commit 9032a866c477bf38a6e19bae3939fecee6d9df68 in branch refs/heads/master 
from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=9032a86 ]

ISIS-665: auto-escalate application exceptions to fatal exceptions

In addition:
- added RecoverableException, NonRecoverableException, FatalException into the 
hierarchy
- RecoverableException is synonym for ApplicationException (immediate supertype)
- NonRecoverableException is synonym for FatalException (immediate supertype_
  - basically any other runtime exception thrown by the app

extended ToDoItem to demonstrate usage.


> ObjectActionImpl should escalate a thrown Isis ApplicationException to its 
> underlying cause if the transaction is in a state of mustAbort.
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ISIS-665
>                 URL: https://issues.apache.org/jira/browse/ISIS-665
>             Project: Isis
>          Issue Type: Improvement
>          Components: Core, Objectstore: JDO
>    Affects Versions: objectstore-jdo-1.3.0, core-1.3.0
>            Reporter: Dan Haywood
>            Assignee: Dan Haywood
>            Priority: Minor
>             Fix For: objectstore-jdo-1.4.0, core-1.4.0
>
>
> We hit a situation whereby a bug in the domain code was causing a 
> JDOUserException to be thrown (missing a mandatory-field), but then throwing 
> an org.apache.isis.applib.ApplicationException.  
> This exception is only intended for non-fatal exceptions.  Isis therefore 
> attempted to commit the transaction subsequently only to find it had already 
> been aborted.
> ObjectActionImpl should try to identify this programming error, and "do the 
> right thing", which is probably to throw the ApplicationException's 
> underlying cause (else a runtime exception if there is none).
> NB: this ticket should also include adding some documentation to the website, 
> since this is a pretty subtle issue.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to