I think there is a need for some more detailed documentation on exception handling in Spring Web Flow. It is nice as it seems a lot of flexibility is provided, but it can be overwhelming trying to figure out the correct place to do things or why to use one over the other. I think it would be helpful to get some detailed documentation on the different places and types of exception handlers that exist and what the best practices are.
Here are a few that I have run across, and I would guess that there are even more options out there:
Transitions with on-exception attribute
At first I thought it was a no-brainer to use one of these as an inherited global-transition in across all flows as this seemed very straightforward for application wide error handling. If you want to use things like \ flows however, it doesn't seem flexible enough to catch all exceptions (like on-exception="java.lang.Exception") but still allow your AccessDenied exceptions to bubble up to spring security where they typically would be handled
\ implementations
Can we document why this would be used instead of or in addition to an on-exception transition? There seems to be a bit more flexibility with this, but I have seen in some of the forums that you are responsible for rendering your own view using flow APIs if you take this approach. Some clarification here would be nice and what types of things are safe to do here (i.e. can we manually set states/transitions, render views, externally redirect, etc.) and examples of the correct ways to do them
FlowExecutionListeners - the exceptionThrown method
You can also get notification of exceptions via registration of a FlowExecutionListener and reacting to an event in the exceptionThrown method. What types of things are safe/appropriate here? I have done things like set flow/flash related variables that can then be used in the flow definition (i.e. <transition on-exception="my.exception" to="${flowScope.viewSetInListener}"), but am curious what else is safe/possible here.
Spring MVC HandlerExceptionResolvers
It seems as though anything not handled by a flow exception handler or exceptions that occur outside of a flow get handled by the MVC exception resolvers. Of note here is that once again, you need to do some work to allow AccessDeniedExceptions from a flow be allowed to bubble up to the Spring Security Filter. What are some correct usages of this, especially in the case where you are using JSF as a view layer and relying on Webflow for rendering instead of the FacesServlet (assuming your error page will make use of your look and feel that is already defined via JSF templates).
Ryan Rich opened SWF-922 and commented
I think there is a need for some more detailed documentation on exception handling in Spring Web Flow. It is nice as it seems a lot of flexibility is provided, but it can be overwhelming trying to figure out the correct place to do things or why to use one over the other. I think it would be helpful to get some detailed documentation on the different places and types of exception handlers that exist and what the best practices are.
Here are a few that I have run across, and I would guess that there are even more options out there:
Transitions with on-exception attribute At first I thought it was a no-brainer to use one of these as an inherited global-transition in across all flows as this seemed very straightforward for application wide error handling. If you want to use things like \ flows however, it doesn't seem flexible enough to catch all exceptions (like on-exception="java.lang.Exception") but still allow your AccessDenied exceptions to bubble up to spring security where they typically would be handled
\ implementations
Can we document why this would be used instead of or in addition to an on-exception transition? There seems to be a bit more flexibility with this, but I have seen in some of the forums that you are responsible for rendering your own view using flow APIs if you take this approach. Some clarification here would be nice and what types of things are safe to do here (i.e. can we manually set states/transitions, render views, externally redirect, etc.) and examples of the correct ways to do them
FlowExecutionListeners - the exceptionThrown method You can also get notification of exceptions via registration of a FlowExecutionListener and reacting to an event in the exceptionThrown method. What types of things are safe/appropriate here? I have done things like set flow/flash related variables that can then be used in the flow definition (i.e. <transition on-exception="my.exception" to="${flowScope.viewSetInListener}"), but am curious what else is safe/possible here.
Spring MVC HandlerExceptionResolvers It seems as though anything not handled by a flow exception handler or exceptions that occur outside of a flow get handled by the MVC exception resolvers. Of note here is that once again, you need to do some work to allow AccessDeniedExceptions from a flow be allowed to bubble up to the Spring Security Filter. What are some correct usages of this, especially in the case where you are using JSF as a view layer and relying on Webflow for rendering instead of the FacesServlet (assuming your error page will make use of your look and feel that is already defined via JSF templates).
Affects: 2.0.3
17 votes, 9 watchers