Jason, That's exactly what I wanted to know. Thanks!
Allen On Fri, Jan 9, 2015 at 12:12 PM, Jason Porter <[email protected]> wrote: > Oh, interesting. Looks like the docs changed and I didn't notice that. > That's unfortunate. > > If you take a look at > https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/exception/control/ExceptionHandlerBroadcaster.java#L60, > which is the method that actually handles calling the handlers and taking > care of their returns. I know it's a bit ugly, but after all the years and > five or six attempts at making this better, that's the best I've come up > with. Anyway, you can see one of three outcomes happens > > 1) It was aborted, which in that case the isHandled method will be false > and you'll have to bubble that exception up the call chain (In my > experience this should only make sense in validation instances) > 2) It was handled and isHandled will return true. Of course based on your > logic you may want to return a null or some other default value. > 3) The main exception or some other exception is thrown, in which case > there isn't anything you can do. > > Does that help? > > On Fri, Jan 9, 2015 at 10:26 AM, Allen Cunningham < > [email protected]> wrote: > >> Jason, >> >> Maybe I can rephrase my question: What should the catch block in the >> InventoryActions example be returning? >> >> Allen >> >> On Fri, Jan 9, 2015 at 9:59 AM, Jason Porter <[email protected]> >> wrote: >> >>> Just woke up and read this. I think I need to become a bit more awake >>> before I dig back in to fully understand the question :) I'll get back >>> to >>> you later today. >>> >>> On Friday, January 9, 2015, Allen Cunningham <[email protected]> >>> wrote: >>> >>> > I am trying to use DS Exception Control in a new project. I recently >>> > discovered that the method that fires the ExceptionToCatchEvent also >>> > returns. >>> > >>> > It may seem odd that I was surprised, but the example InventoryActions >>> > class in the DS documentation doesn't return anything when the >>> exception >>> > occurs (which in fact won't compile). I had assumed that DS was doing >>> some >>> > magic to alter the return path. Now that I look at it closer it is >>> obvious >>> > - firing an event shouldn't change control flow. >>> > >>> > Can someone confirm that the intent of Exception Control is to provide >>> a >>> > mechanism IN CONJUNCTION with some degree of normal exception handling? >>> > What I mean by this is that it seems I need to either re-throw the >>> > exception or return a null to the caller, then use DS exception >>> handling to >>> > handle it at higher levels in the call stack. >>> > >>> > Don't get me wrong - I think this is super cool and it works very well >>> in >>> > my app! I just want to be sure I'm not missing something. >>> > >>> > Allen >>> > >>> >>> >>> -- >>> Jason Porter >>> http://en.gravatar.com/lightguardjp >>> >> >> > > > -- > Jason Porter > http://en.gravatar.com/lightguardjp >
