Exception Control return flow

[Allen Cunningham <cu...@olsdallas.com>]

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

Re: Exception Control return flow

[Allen Cunningham <cu...@olsdallas.com>]

Jason,

That's exactly what I wanted to know. Thanks!

Allen

On Fri, Jan 9, 2015 at 12:12 PM, Jason Porter <li...@gmail.com>
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 <
> cunningham@olsdallas.com> 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 <li...@gmail.com>
>> 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 <cu...@olsdallas.com>
>>> 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
>

Re: Exception Control return flow

[Jason Porter <li...@gmail.com>]

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 <cu...@olsdallas.com>
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 <li...@gmail.com>
> 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 <cu...@olsdallas.com>
>> 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

Re: Exception Control return flow

[Jason Porter <li...@gmail.com>]

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 <cu...@olsdallas.com>
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