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
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.
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.
@Chad - You can actually turn off HTTP friendly errors in IE.
http://technet.microsoft.co...
That may help as well.
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.
I usually just have them email me a cfdump of cfcatch. That does the trick most of the time.
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.
Wont just turning on debugging show him the exact problem, even errors wrapped in try catch statements should show up in debugging i think.....
Debugging would show an error, but only in a very short form. Not the complete stack trace.
@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
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.
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.
@Larry - yeah - thats an option too - but I don't use it for exactly that reason - the popup.
[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]
Genius! Thanks, Ray!
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.
However, using that "Enable HTTP status codes" option allows for better error handling though IIS. Especially for the 404 missing cfm page issue.
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.
Hey Bob, how did you resolve the issue regarding to the wrong status code?
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.
Glad it helped. :)
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.
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!
Heh, no, it is a mistake. I'll fix. (Should be up in 15 minutes.)
All good now, thanks Ray. Gonna go have a read of that guide and level-up my CF error handling skills :)