After my emails about exception handling and invalid event handling, I
had everything working nicely in Beta 3 (with the patch to persist
"invalidevent" across the redirect).
I upgraded to the latest in SVN after Luis said it was "almost Beta 4"
and my invalid event handler stopped working.
The first problem was that when your onInvalidEvent is triggered, the
default view is still the *original* requests default view (which may
or may not exist - but probably will not). You have to explicitly call
event.setView() to specify what to show the user.
I don't know whether this is intentional or not - it caught me out.
The second problem was that "invalidevent" is stored in the *private*
request context now and I had to add a third true argument to my
getValue() call in my invalid event handler in order to retrieve the
value.
Again, I don't know whether that change was intentional or not -
"invalidevent" was definitely in the (public) request context in Beta
3 (well, it was there in one invalid event case but simply missing in
the other case - the two cases being event=bogus.any and
event=valid.bogus, i.e., it depended whether it was a missing handler
or a missing method/action).
LOL,
The wonders of beta software. In summary, onInvalidEvent did not work as reported since version 2.6.4 as when the actual handler was invalid, the page stayed and the invalid event just overrode the event. When the handler existed but the action did not, the service was relocating and saving the invalid event.
This was the behavior in 2.6 which was not consistent and the second part did not resolve an issue where 404’s where needed instead of a 302 relocation.
Thus, for 3.0.0 we looked at the whole picture and redesigned it so it would be consistent across the board for missing event handlers and missing actions. Therefore, now the invalid event is saved in the private request collection so it can be retrieved if needed and now, when a missing handler or event is detected and the onInvalidEvent is detected it hijacks the event so the event is now the one that executes.
So now it is consistent.
On another note, just for informational purposes, we added another exception handler at the handler level for 3.0.0. This follows suit to the by convention method signatures. Therefore, you can now create an “onError(event,faultAction,exception)” in your handler and it will respond to ANY error that ocurrs at that same handler level. This is useful if you have created a base handler class that deals with certain areas of your application, such as RESTful handlers, Flex Handlers or even common MVC functionality.
The top level exception routines are the exceptionhandler event you can configure in your main configuration and the onException interception point. Both accomplish the same but in different approaches. The interceptor level is my favorite as it is decoupled and can produce an AOP chain of execution whenever errors occur in your application.
I hope this helps Sean. Sorry that you had to go through some loops, but changes have to be done towards our 3.0.0 RC.
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
So now it is consistent.
Consistent good. I was just surprised that the original (bad) event's
default view selection remained and that the invalid event handler had
to explicitly set a view...
On another note, just for informational purposes, we added another exception
handler at the handler level for 3.0.0. This follows suit to the by
convention method signatures. Therefore, you can now create an
"onError(event,faultAction,exception)" in your handler and it will respond
to ANY error that ocurrs at that same handler level. This is useful if you
have created a base handler class that deals with certain areas of your
application, such as RESTful handlers, Flex Handlers or even common MVC
functionality.
Useful.
I blogged a whole bunch of stuff about ColdBox Error Handling tonight
so maybe you could add that as a comment?
Awesome! Thanks for your comments Sean. It is always great to hear comments about this. There is soooooo much room for improvement. So please, post always!
And yes, it is not apparent what you mention, I jotted it down as a great Note item.
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com