Application.cfc OnRequest() Method Affects OnError() Arguments

Posted July 23, 2007 at 9:22 AM

Tags: ColdFusion

The other week, Thomas Messier pointed out to me that my ColdFusion Application.cfc Tutorial was a bit incomplete in the fact that it did not address the changes in the OnError() event method arguments that depend on the existence of the OnRequest() event method. To be totally honest, I did not know anything about this. I pretty much always use the OnRequest() event method, so I have never had to deal with errors that occur outside of it.

I set up a quick, little test application to see what was actually going on. In the Application.cfc ColdFusion component below, my OnRequestStart() checks for a Delete flag in the URL. If it exists, it simply deletes the OnRequest() method. Then, I throw an error in my index.cfm page and compare the two different sets of arguments.

My ColdFusion Application.cfc:

 Launch code in new window » Download code as text file »

And then, my simple index.cfm:

 Launch code in new window » Download code as text file »

Here, I am simply referring to a variable, Y, that does not exist.

When I run the page without any query string flag, the Application.cfc runs with the OnRequest() method and produces this OnError() arguments CFDump (I have collapsed some of the items for better display):

Now, let's compare that to what happens when I call the same page, but this time, I send the "?delete" flag that will cause the OnRequestStart() method to delete the OnRequest() method from the Application.cfc. This time, my CFDump output is much smaller:

The difference here, as Thomas Messier pointed out, is that the error generated without the OnRequest() method's presence does NOT have the RootCause structure. I don't know why this is, but this is certainly good to know.

Download Code Snippet ZIP File

Post Comment  |  Ask Ben  |  Other Searches  |  Print Page

• Add To Del.icio.us
• Add To Digg
• Add to Spurl.net
• Add to Wists
• Add to Simpy
• Add to Newsvine
• Add to BlinkList
• Add to Furl
• Add to reddit
• Add to FARK
• Add to BlogMarks
• Add to Yahoo! My Web
• Add to smarking
• Add to Ma.gnolia
• Add to Segnalo

Reader Comments

not sure what the difference is, but i will have to investigate a little. The application.cfc i am using does not have an OnRequest() and the ARGUMENTS.EXCEPTION.RootCause struct _is_ there, however if i extend that cfc and put my own OnError handler in the cfc that is extending the main one the ARGUMENTS.EXCEPTION.RootCause struct _is not_ available.

Very odd, this is definitely something that needs to be cleared up!

@Joey,

That is a funky difference!

I am using the OnError function in application.cfc and I noticed a strange occurance. If I mistype a cf tag (ie. <cfssset x = y />) the OnError does not catch it, just a generic CF error is displayed. Furthermore even if I use a cftry cfcatch around that code, with type = "any", CF still displays its own error and will not allow me to catch it.

Not that I plan on purposely adding bad code, but it would be nice if I could catch it just in case. Do you have any idea if this is a known bug?

I forgot to mention that my mistyped tag was located in my index.cfm file.

Interestingly enough I created the same error in a cfc which I called as an object. In that way the error was caught and displayed the way I wanted to from the OnError function.

Am I missing something?

@Jason,

It's possible that parsing errors are not handled in the same way; theoretically, a site would never go live *with* parsing errors.

It's also possible you have an error in your onError() method handler; if you do, the original error will be allowed to bubble up to the top (without the error in the onError() event handler being displayed).

@Ben

Thank you for responding so quickly.

I thought I would post my code. I was just doing a simple POC when I noticed this.

application.cfc:
----------------------------------------
<cffunction name="OnRequest" access="public" returntype="void" output="true">

<cfargument name="TargetPage" type="string" required="true" />

<cfinclude template="#Arguments.TargetPage#" />

<cfreturn />
</cffunction>

<cffunction name="OnError" access="public" returntype="void" output="true">

<cfargument name="pass_cfcatch" required="Yes" type="any" />

<cfdump var="#pass_cfcatch#" />
</cffunction>
----------------------------------------

The file that the OnError would not catch was onerror_parsing.cfm with just <cfssset x = y /> in it.

The other file that OnError DID catch was onerror_parsing_cfc.cfm that called a cfc with <cfset Variables.onerror_template = createObject("component", "onerror_parsing").init() />. In the onerror_parsing.cfc file I had the same <cfssset x = y /> in it.

I only noticed this cause I was trying to see how the OnError would react to different types of errors. I agree with you and hope that any error like this would never reach the live server (especially since I have a Dev AND Staging server), I just thought it was worth noting.

Thanks again.

Okay, sorry about flooding your comments, but on a whim I tried one more thing. I made no changes to the application.cfc file I posted above, but this time I created another .cfm file that simply had <cfinclude template="onerror_parsing.cfm" /> in it.

When loading it this way the OnError in the application.cfc caught and dumped the error.

Of course, I think the moral of this story is don't let these kind of errors make it to your live server, but again, I thought it was worth noting.

On a side note, I did work for a company that had a programmer (who was eventually denied access to the live server) who kept insisting on making changes directly on the live server - he would occasionally make these kind of errors. Not fun.

@Jason,

Hmm, odd that it would catch one parsing error and not the other. There's probably something subtle and tricky going on :)

@Jason and @Ben,
I've been doing some CF9 refactoring on our systems and noticed an odd occurrence with onError as well.

Found a way to work around my problem, but what I saw was...

Background:
Our platform is OO and creates a CFC (our API) into the session scope onSessionStart. That API is then referenced in each CFC's variables scope so it's easily accessed from any function.

If an error was generated on the same request as the one that ran onSessionStart, the onError function call had no access to the alias in the variables scope. As if it was never put there. But it IS there as that happens in the constructor of the base-class that each CFC extends.

So a call of
<cfset id = API.getUserID()> fails in the error handler, but
<cfset id = session.API.getUserID()> works.

Again, if I cause the error in a request AFTER the session is created, everything works. But if the session is instantiated in that request I get a standard CF error saying it can't find API.

I wish I could say I understand what's happening so-as to shed light on this topic, but maybe my experience could help somehow.

For clarification, the CFC being called to generate the error is not directly called, it's being processed by the API, so the API MUST be fully initialized and loaded into the variables scope to even execute the error function.

-Bry

Post Comment  |  Ask Ben

Post A Comment

Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Formatting: <strong>bold</strong> <em>italic<em>
	Remember my information
	Subscribe to entry *
	Send me a copy of this comment (as part of the comment thread)

 

* If you subscribe, any new posts to this thread will be sent to your email address.