Changes to web flow action proposal

[Marvin S. Addison]

> How about this?
>
> if (doPreExecute(profileRequestContext)) {
> 	try {
> 		doExecute(profileRequestContext);
> 	} catch (ProfileException e) {
> 		try {
> 			doPostExecute(profileRequestContext);
> 		} catch (RuntimeException re) {
> 			// log the RE
> 		}
> 		throw e;
> 	} catch (RuntimeException e) {
> 		try {
> 			doPostExecute(profileRequestContext);
> 		} catch (RuntimeException re) {
> 			// log the RE
> 		}
> 		throw e;
> 	}
>
> 	doPostExecute(profileRequestContext);
> }

That's more elaborate than I was thinking, but it accomplishes the same 
thing. Explicitly catching the exception like above provides an 
additional capability with a small tweak; you could pass the exception 
into the handler via an overloaded doPostExecute method:

doPostExecute(profileRequestContext, e);

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);
   }
}

> Assuming your point is that we should log and swallow a runtime error in
> the case that an exception is already in progress, but not otherwise,
> which would be something I could probably live with.

That's correct.

> But in C++, you really don't want to swallow RuntimeException (the
> equivalent is catching (...)) because it destablizes the system to do so.

There's no such concern in Java. The only concern is losing the error 
context that is most important to program execution, which I assumed was 
that of doExecute. If you want _both_ you could create an Exception 
class that stores them both and throw that in case both fail.

M