Exception Handling Error in the Nightly?

[Brian Klaas]

I'm probably just being thick and missing something simple here, but
I'm having issues with exception handling. If I force an error by
putting an event name in to the URL string which is not defined in my
Mach-II config file, I'm getting the standard CF error with the
following message:

Type: MachII.framework.Event || Message: The value returned from the
getCurrentEvent function is not of type MachII.framework.Event.

The error message is being specifically generated inside a plugin, and
the call path is as follows:

The error occurred in /Library/WebServer/Documents/MachII/framework/
PluginManager.cfc: line 633
Called from /Library/WebServer/Documents/MachII/framework/
EventContext.cfc: line 527
Called from /Library/WebServer/Documents/MachII/framework/
RequestHandler.cfc: line 196
Called from /Library/WebServer/Documents/MachII/mach-ii.cfc: line 195
Called from /Library/WebServer/Documents/core/Application.cfc: line 84

Now in all my other apps, when I force an error by putting a non-
existent event name in the URL string, the exception event is normally
generated and the framework routes to the event defined as my
exception event in the base Mach-II XML config file. I can then do
processing there, like send myself an email or output a message
specifically stating that they're looking for a page which doesn't
exist, and so on.

I'm using the nightly (I pulled down a copy from the repository about
an hour ago, just to make sure I'm absolutely up to date), and am
utilizing a local development environment as defined in my
environmentConfig.XML.

Is there something in the environment code that just outputs the CF
exception rather than routing through to the exception event, a bug in
the nightly for exception handling, or something else that I'm
missing?

brian

[Peter J. Farrell]

Brian,

Just a couple of questions for clarification. Are you using the
handleException() plugin point in your other applications? And if you
are, are you calling arguments.eventContext.getCurrentEvent()?

Here's the low down. In the preProcess() plugin point, we all know that
the event processing hasn't started yet and we need to get the 1st event
of the in the queue using getNextEvent().

Now, in the handleException point() -- there is an cart before the horse
situation when that point is called before event processing begins (as
in the case you illustrate). So you need to do something like this in
your handleException() point (excuse my brevity in code by leaving off
attributes):

<cffunction name="handleException">
<cfargument name="eventContext"/>

<cfset var event = "" />
<cfset var missingEvent = "" />

<cfif arguments.eventContext.hasCurrentEvent()>
<cfset event = arguments.eventContext.getCurrentEvent() />
<cfelse>
<cfset event = arguments.eventContext.getNextEvent() />
</cfif>

<!--- If it is due to the a missing event args and you'll want the
missing event as well, you need to do: --->
<cfif arguments.exception.getType() EQ
"MachII.framework.EventHandlerNotDefined">
<cfset missingEvent = event.getArg("missingEvent") />
</cfif>
</cffunction>

The conundrum is that handleException (unlike all other plugin points)
can occurs before event processing has begun and while events are being
processed. So it is a little bit special because of that.

There is a ticket #385 that brings up the issue that exception that
occur in the preProcess and postProcess (and I've mentioned that
handleException is another pinch point).

We could probably use a bit of spit and polish on making the
handleException() plugin point easier to work with (illustrated above).
If you have any ideas on how to do that, feel free to suggest them --
I'm all for making it a snap to deal with as long as we can maintain
backwards compatibility. Maybe it's as simple as adding a third
argument called "currentOrNextEvent".

Best,
.Peter

P.s. If you feel so inclined, I encourage you to use my email here as a
basis for creating a new FAQ on the subject. We have one for getting
the event during the preProcess point -- sounds like we need for
exception handling. Any help is most appreciated.

Brian Klaas said the following on 11/12/2009 01:42 PM:

[Peter J. Farrell]

Oh, again - please file a ticket at trac.mach-ii.com regarding making
handleException() easier to deal with in the terms of getting the
event. Maybe somebody has an idea to make it real slick (and possible
make it easier to get the event in the preProcess -- although I don't
quite like the idea of adding an argument to the preProcess to pass in
the event). Just thinking out loud...

.Peter

P.s. I'll be watching the Trac RSS feed for that ticket and FAQ...now,
if that ain't an arm twist ;-)

Brian Klaas said the following on 11/12/2009 01:42 PM:

[Brian Klaas]

Hi Peter -

To answer your original questions:

Are you using the handleException() plugin point in your other
applications? And if you are, are you calling
arguments.eventContext.getCurrentEvent()?

In my production applications running 1.6, these functions do exist,
but they're essentially empty (the default left in from the plugin
template that comes with the skeleton) -- lazy, I know, yes.

<cffunction name="handleException" access="public" returntype="void"
output="true">
<cfargument name="eventContext" type="MachII.framework.EventContext"
required="true" />
<cfargument name="exception" type="MachII.util.Exception"
required="true" />
<cfoutput>&nbsp;appConstantsPlugin.handleException()<br /></
cfoutput>
<cfoutput>#arguments.exception.getMessage()#</cfoutput>
</cffunction>

However, although these functions are merely placeholders, the
exception event is properly called.

In the app I'm currently developing using the latest nightly, running
locally, and using the environment config, the skeleton handleException
() function exists exactly as above, and it's not properly calling the
exception event. In my production apps, I'm using 1 or 2 plugins, but
in the app I'm currently developing, there are 4 that get called. I
don' think this would make any difference, but I thought I'd provide
as much detail as I can.

I'll go back and utilize the sample code you provided, and work from
there. I just found it weird that something that would work under 1.6
wouldn't work under 1.8.

And, yes, I'll update the wiki with a new FAQ or add to the existing
one on Mach-II exception handling, and add a new ticket, though I
don't know how you could make it much easier to get the event in
handleException() without hacking up the framework.

brian

[Brian Klaas]

Oh - and to add to my confusion: if I completely remove the
handleException() plugin point from all of my plugins because I don't
want to do any custom exception handling and just let the default
exception event be called by the framework, the exception event is
_not_ called and I get the standard CF exception message of:

Type: MachII.framework.Event || Message: The value returned from the
getCurrentEvent function is not of type MachII.framework.Event.

I've got to be missing something really simple here.

brian

[Peter J. Farrell]

Brian,

Ok, it's clear that getCurrentEvent() is being called somewhere we
just got to find out where.

* By chance, do you have an EmailLogger defined?
* Can you email me the complete exception you get when you *do not*
have any handleException() plugin points defined?
* You may need to go into the PluginManager (around line 633) and do a
straight <cfdump var="#cfcatch#/></cfabort> in the try/catch block.

.pjf

[Brian Klaas]

I am using an EmailLogger, defined at the parent app level. I'll email
you all the rest of the information.

brian

[Peter J. Farrell]

Thanks for the info Brian.  I requested a few more items from you off list.  I think were getting closer to figuring what is going on.

.pjf

Brian Klaas said the following on 11/16/2009 09:24 AM:

[Brian Klaas]

To wrap this one up: I was calling

<cfset var event = arguments.eventContext.getCurrentEvent() />

in the preProcess() method of one of my plugins. While this didn't
cause the framework to bomb out under 1.6, it does under 1.8 because
they've cleaned up some things under the hood. It's not a
compatibility issue with Mach-II 1.8. It's now behaving as it should
have behaved from the get-go.

By changing the call to

<cfset var event = arguments.eventContext.getNextEvent() />

as I should have (because in preProcess, you have to get the next
event, as there's not a "current" one yet), and everything works just
fine.

brian

[Peter J. Farrell]

FYI, there is an FAQ on the wiki about this for future reference for people that search this issue:

http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/wiki/FAQHowToGetEventInPreProcess

Glad, it was all resolved Brian.

Brian Klaas said the following on 11/17/2009 12:22 PM: