Changes to web flow action proposal

[Cantor, Scott]

On 4/18/13 10:10 AM, "Marvin S. Addison" <marvin.addison at gmail.com> wrote:

>That puts an awful lot of discipline on implementers of doPostExecute to
>catch all exceptions. Without strict adherence, an exception raised by
>doExecute would be dropped and replaced with that emanating from
>doPostExecute. I have used a library with plugins using the pattern
>above and have cursed the lack of additional error handling in the
>finally block. I hope you'll consider a try/catch block that wraps
>doPostExecute if you go with this design.

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


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.

But in C++, you really don't want to swallow RuntimeException (the
equivalent is catching (...)) because it destablizes the system to do so.
Even here it makes me uncomfortable. Perhaps you have a different view,
but I'm not sure a RuntimeException shouldn't supersede a ProfileException
anyway, in which case my original code wasn't all that off.

-- Scott