Don’t let your error handling “run around naked”: why you should be sure to log errors in your error handling.
Did you know that if you “handle” an error in CFML, that error will NOT be logged to CF’s application.log file, like errors typically would be?
And do you know why that could be a problem, and how easily you can solve it, in one line with CFLOG? Read on.
Why it’s a problem if errors are not logged
I see this often: people create an error handler for their app (or page or server), primarily because they want to hide the error from the user, and then secondarily they typically save the error in a database or email that they then look at later to “manage the errors”.
The problem is that:
- sometimes other folks doing troubleshooting on that server may look at the CF logs–and if errors are handled this way and thus not logged, these other folks would not know the error was even happening
- or they may not know about the UI that was created by the folks wanting to better “manage the errors”
- or the people who WERE getting the errors by email maybe setup a rule and file them into a folder and forget about them–or worse, they may leave the company, so perhaps few know the errors are even happening
An even worse problem happens when those who put in a try/catch to handle an error may for some reason just have that code ignore the error and do nothing at all. I’ve seen that bite people who had no idea how often the error was happening.
And yes, I realize there can be situations where someone may intentionally want to NOT log errors, perhaps because they are happening very very often and they just don’t want their logs flooded with the error. That’s a pretty rare sitaution, though.
My focus here really is on traditional error handling code where folks DO think to email the error or save it to a database, but they just don’t even think to log the error. And they don’t realize it won’t be logged, and maybe they aren’t considering how someone could be relying on the logs to tell them if errors are happening (such as when someone is troubleshooting CF server problems, or just wondering “how the server is doing?”)
How easily you can add error logging
<cflog text="Error: #WhateverVariableHoldsTheErrorMsg#">
Note that I don’t name here what variable you should log, because it could differ based on the kind of error handler: whether you’re in a try/catch error handler, an onerror method of application.cfc, a site-wide error handler, or the old cferror type=”exception” error handler. You can determine the exact variable from whatever you currently are writing to your database or email.
CFLog will by default write to the application.log file (more on that in a moment).
(And if you’re totally new to CFML error handling, I will note that I wrote a multi-part intro to the subject in…err…2002. Believe it or not, it all still applies. It was before application.cfc, but again all the concepts apply. And since then, there have been new error handling frameworks which are quite compelling.)
But my point is: get the error logged.
Some other points
Before closing, here are a couple of related points for those who may not do much with cflog/writeog.
- First, note that you can override that default location using the FILE attribute of cflog/writelog, which if specified writes to a .log file of that name. So file=”myerrors” would write to an myerrors.log file, in the CF logs folder, and creating the file if needed.
- As for the TEXT attribute (or first argument of the function), you can of course log ONLY the variable, and not preface it with the phrase “Error: “. I just did that to show folk how they could use any string and/or variables.
- And there is also an available “type” attribute of the tag (or argument of the function), but there’s more to it than meets the eye and I won’t elaborate on it here.
You can find more about the tag and the function, as well as error handling in general, in the respective Adobe CF doc pages:
Note that the page offered in that last link itself has links to still other pages with more detail on CFML error handling (so it’s more substantial than it may seem at first glance). And some day I’ll reprise and update my multi-part blog post on error handling, as well. 🙂