Ask a Jedi: Stop hiding a ColdFusion error

I've blogged many times before about the need for proper error handling. (See the guide) for more information.) But this week a reader came to me with an interesting problem. His ColdFusion site was throwing an error of some kind, but all he saw was a 'nice' error page, and not the real error. Basically, he needed to "roll back" the error handling so he could determine the real nature of the bug. These are the steps I walked him through including the 'final' issue that ended up being the main culprit.

Step one - if the error is happening on a certain page, like foo.cfm, open up foo.cfm and see if a try/catch is suppressing the error. If so, you can either remove the try/catch tags themselves, or inside your cfcatch do a quick cfdump on the exception information.

Step two - check to see if error handling was enabled in an Application.cfm file. Remember that ColdFusion will look for this file in the current folder and any folder above it. You need to look for that (or an Application.cfc file) in ever folder until you hit web root. (Note that in ColdFusion 9 you can limit how far 'up' the server will look.) When you find that file, search for a cferror tag. This will tell ColdFusion to run a template when an error occurs. If the Application.cfm cfincludes anything else, check those files as well.

Step two and a half - repeating the same logic above, look for an Application.cfc file. Application.cfc files can have both a cferror tag and an onError function. If you see them - comment them out.

Step three - You can define an error handler within your ColdFusion Administrator that applies globally. This one has tripped me up before. You will find it in the Settings page under "Site-wide Error Handler."

Step four - If you get an error, but not all the information you want (like a line number), then ensure that you enable Robust Exception Information. I'm normally warning people to turn off this setting, but in development you almost always want it turned on.

So... I thought that was it but unfortunately he still couldn't see his error. All he saw was:

500 - Internal server error. There is a problem with the resource you are looking for, and it cannot be displayed.

Then something occurred to me. Back in the ColdFusion Administrator I asked him if he had Enable HTTP status codes turned on. Guess what? He did. What he was seeing was an IIS error handler. Once he turned that off he started getting his "naked" ColdFusion errors again.

Archived Comments

Comment 1 by Raymond Camden posted on 11/17/2010 at 3:45 AM

So a guy on Twitter - ValentineErb - just made a darn good point and I should have brought it up. If your site makes use of fancy CSS for layout (and by fancy I mean anything beyond my meager skills ;) than it is possible that your error, or CF's default error display, may not render correctly. I see this all the time with debugging information.

Unfortunately there isn't much you can do about that outside of hiding your normal site layout for an error. I can see doing that in development to make errors easier to read for both QA and development.

Comment 2 by Chad posted on 11/17/2010 at 3:47 AM

I have seen this 500 error when i use IE. It is only certain error types. I switch to FireFox or Chrome and i see the real error. I will check my Enable HTTP Status Codes. I always assumed it was something strange with IE.

Comment 3 by Daniel Garcia posted on 11/17/2010 at 4:14 AM

@Chad - You can actually turn off HTTP friendly errors in IE.

http://technet.microsoft.co...

That may help as well.

Comment 4 by Chris Mallinson posted on 11/17/2010 at 4:21 AM

I always give myself back-door access to raw error messages with an admin function or switch that bypasses "nice" error pages for my session or IP.

For CF errors that are messed up by CSS, I usually just use the "developer" menu in Safari or Firefox to turn off CSS entirely.

I often do all my troubleshooting with CSS turned off.

Comment 5 by JC posted on 11/17/2010 at 4:51 AM

I usually just have them email me a cfdump of cfcatch. That does the trick most of the time.

Comment 6 by Michael posted on 11/17/2010 at 4:55 AM

When I work on a site to ensure
1.) That i handle errors appropriately even when I don't know they are occurring.
2.) That I know what the errors are and not letting people who don't need to know. I normally have onError mail me the page, the address, the Exception, the referer, the form fields, the session fields, and any other relevant configuration options.

Comment 7 by shakti posted on 11/17/2010 at 9:07 AM

Wont just turning on debugging show him the exact problem, even errors wrapped in try catch statements should show up in debugging i think.....

Comment 8 by Raymond Camden posted on 11/17/2010 at 7:21 PM

Debugging would show an error, but only in a very short form. Not the complete stack trace.

Comment 9 by Larry C. Lyons posted on 11/17/2010 at 9:54 PM

@Ray: "If your site makes use of fancy CSS for layout ...than it is possible that your error, or CF's default error display, may not render correctly."
That's where the dockable.cfm option come in very handy - that nicely bypasses all the fancy CSS that messes up the classic debugging display. Mind you the popup window does get old very fast when it shows up on each and every page.

larry

Comment 10 by JC posted on 11/17/2010 at 10:02 PM

I remember way back when I was working with Websphere for something, my coworker set it up to write all the errors to a jabber server, and we kept a copy of GAIM open... that way we had all the stack trace stuff in front of us without having to do anything with our error handling. I wonder now and then if CF could do something similar. But usually just having it email me the cfdump of cfcatch does the trick, because it's so rare that I encounter anything that's screwed up enough to need any more detail than that in any system that's already got the error handling added to it.

Comment 11 by Raymond Camden posted on 11/17/2010 at 10:09 PM

There is a company who made it SUPER easy to send IMs. I forget their name - I reviewed them on the blog about two years ago.

Comment 12 by Raymond Camden posted on 11/17/2010 at 10:09 PM

@Larry - yeah - thats an option too - but I don't use it for exactly that reason - the popup.

Comment 13 by David posted on 11/22/2010 at 6:26 PM

[Shameless-plug]
Step-debugging is the de-facto in many other languages and would be very helpful here. FusionDebug can break on exception and show you exactly what's happening without needing to check through the stack of code for try/catch. It can run against your production server without your users needed to know anything about it. It's *very* fast and plugs into Flash Builder/CFEclipse/CF Builder/any-other-eclipse-environment.
[/Shameless-plug]

Comment 14 by Grant Powell posted on 9/6/2013 at 5:03 PM

Genius! Thanks, Ray!

Comment 15 by Alex G. posted on 7/25/2014 at 10:15 PM

Through the years I hit these nuggets from time to time. Thanks again. It was driving me nuts and didn't think about that last step.

Comment 16 by Bob posted on 8/24/2014 at 4:47 PM

However, using that "Enable HTTP status codes" option allows for better error handling though IIS. Especially for the 404 missing cfm page issue.

Comment 17 by Robert posted on 10/30/2014 at 4:24 AM

Thanks for this pointer. I question why the gentleman wasn't checking his ColdFusion logs to see what they identified as the source of the error.

Comment 18 (In reply to #16) by sgr posted on 4/6/2016 at 11:09 AM

Hey Bob, how did you resolve the issue regarding to the wrong status code?

Comment 19 by Leonard Carter posted on 5/16/2017 at 3:21 PM

You, sir, are a golden god! Seven years on, and this post is still saving sanity. I just got my error messages to appear on our dev server for the first time in ages, thanks to you.

Comment 20 (In reply to #19) by Raymond Camden posted on 5/16/2017 at 3:24 PM

Glad it helped. :)

Comment 21 by Saurabh Misra posted on 1/12/2018 at 4:17 AM

Thank you for this article. In my case, "Enable HTTP status codes" and also other settings were proper. But there were some settings in IIS for redirecting to a static HTML page if a 500 error code was returned from CF. I modified those and also modified the web.config file as per this SO answer https://stackoverflow.com/a... and started getting the default CF error response.

Comment 22 by James Cushing posted on 2/15/2018 at 10:14 AM

Ray, part of me hopes this is intentional just for the irony, but the "guide" link in your first paragraph throws a 404. Just thought you should know!

Comment 23 (In reply to #22) by Raymond Camden posted on 2/15/2018 at 1:18 PM

Heh, no, it is a mistake. I'll fix. (Should be up in 15 minutes.)

Comment 24 (In reply to #23) by James Cushing posted on 2/15/2018 at 1:41 PM

All good now, thanks Ray. Gonna go have a read of that guide and level-up my CF error handling skills :)