deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <>
Subject Re: Exception Control return flow
Date Fri, 09 Jan 2015 18:12:46 GMT
Oh, interesting. Looks like the docs changed and I didn't notice that.
That's unfortunate.

If you take a look at,
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 <>

> 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 <>
> 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 <>
>> 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

Jason Porter

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message