Changes to web flow action proposal

[Daniel Fisher]

On Fri, Apr 19, 2013 at 10:00 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 4/19/13 9:24 AM, "Marvin S. Addison" <marvin.addison at gmail.com> wrote:
>
> >I can imagine there may be cases where the post routine might want to
> >know an error occurred. If you don't care about passing in exception
> >context to the post method, the simplest solution:
> >
> >try {
> >   doExecute(...);
> >} finally {
> >   try {
> >     doPostExecute(...);
> >   } catch (Exception e);
> >     log.error("doPostExecute failed", e);
> >   }
> >}
>
> I started there, but I'm not comfortable swallowing a runtime error
> altogether unless something else is being thrown. Since the post method is
> not even supposed to throw, the fact that it does is something I don't
> really want to hide. All of this occurs inside of an overarching execute()
> method. If that throws, I want it to be visible.
>
> The idea of passing the error into the post method is a good one, I've
> done that sort of thing before.


You'll have to choose which exception you want to propagate out if both
doExecute and doPostExecute throw:

Exception executeEx = null;
try {
   doExecute(...);
} catch (Exception e) {
  executeEx = e;
} finally {
  try {
    doPostExecute(...);
  } catch (Exception e);
    if (executeEx != null) {
      log.error("doPostExecute failed", e);
      throw executeEx;
    } else {
      throw e;
    }
  }
}

Or something like this...

--Daniel Fisher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20130419/1c77ee57/attachment.html