onException / onInvalidEvent handling inconsistency

The event handlers guide seems to imply onInvalidEvent and onException
are on an equal footing as Implicitly Declared Events:

http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbEventHandlersGuide

"Implicit Declared Events

There are several events that can be declared implicitly in your
configuration file. They are declared there because they correspond to
several execution points in the life cycle of an application. Let's
explore them:

Default Event : The default event to execute if no incoming event is detected
Request Start Handler : The event to execute at the beginning of every request
Request End Handler : The event to execute at the end of every request.
Session Start Handler : The event to execute at the beginning of a
user's session
Session End Handler : The event to execute at the end of a user's session
Application Start Handler : The event to execute at the startup of the
application
onInvalidEvent : The event to execute when the incoming event is invalid
onException : The event to execute when ANY exception is trapped
within the framework."

Some of these can be handled by an interceptor (e.g., onException) but
some can't (e.g., onInvalidEvent).

onException seems to be the odd fish here. You can declare an
interceptor which fires (when it has an onException() method) and you
can declare the Setting "ExceptionHandler" (which can be any event
handler) and that is also called for an exception.

Is this just "one of those quirks" or are things meant to be a bit
more consistent?

The reason I ask is that I'm trying to centralize error handling in a
ColdBox app and have user-friendly pages for invalid events and for
exceptions and was hoping to streamline things to a single point
(ideally an interceptor). It seems the best I can do is have an
exception handler and an invalid event handler and log/report
exceptions from there?

Are there any "best practices" that folks can offer up in this area?

Sean,

Personally I would use an interceptor, indeed use onException
interception point.
You will have the interceptordata argument, which has a struct key
"exception" and event data access.

You can then call a nextEvent from within your interceptor to do the
error display handling.

Ernst

Hmm, yes, I could just redirect from the interceptor to the "something
went wrong" generic display handler.

Is anyone using the ExceptionHandler for something that cannot be done
with the onException interceptor approach?

Perhaps Luis could comment on these two approaches and explain why
both methods are provided?

Hmm, yes, I could just redirect from the interceptor to the "something
went wrong" generic display handler.

Is anyone using the ExceptionHandler for something that cannot be done
with the onException interceptor approach?

Perhaps Luis could comment on these two approaches and explain why
both methods are provided?

OK, further experimentation shows that if the interceptor redirects to
a friendly display handler directly, the exception is not processed by
the logging subsystem (and I'm relying on that to send bug report
emails). So there's the answer!

Though you could always rethrow the error as part of your redirect.