Skip to main content
J
jeculture
Known Participant
July 19, 2011
Question

Coldfusion Error catching (cftry cfcatch) best practice question...

  • July 19, 2011
  • 1 reply
  • 1530 views

Hey all -

I wanted to get a couple of opinions about this.  Obviously I want to catch any and all errors that hit my server and avoid exposures to my end users, but I didnt know what the most efficient way of doing such was.  Does it make sense to put a cftry cfcatch around the entirety of my code on every page?  (I use a lot of embeds...cfinclude)  Or is that too broad?  How does that effect performance?  Is there another way to auto catch and email all errors and then show the user a custom error page?  I searched around, but I got bits and pieces based on specific requests...not really any "best practice" tips.  Any suggestions would be fantastic.

Thanks much!

    This topic has been closed for replies.

    1 reply

    Owainnorth
    Owainnorth
    Inspiring
    July 19, 2011

    There are no real best practices as such, as it's largely down to your application. The only real "standard" is the onError() method in Application.cfc, which will handle any Exceptions which make their way to it - i.e. any that are not caught by an explicit try/catch block.

    When considering what you are now, I consider this: where do I want to display an error? How far down the line does it matter? There's no right or wrong answer, it's down to you.

    Say you're displaying a page, which is made up of ten includes. If there's an error in one, do you want the other nine displayed, or do you want the whole page to error? If it's the former, wrap each one in its own try/catch. If it's nonsensical to do so, just let the page throw an Exception to get picked up by your Application.onError() method.

    It also depends largely on whether or not an error is "recoverable" - is it of any use telling someone that a small but important part of the page failed becuase of a database issue? Probably not. There's nothing they can do about it, so just throw an error and let your error template sort it out.

    It also depends on the context in which the page is being called - if it's an Application with users, you can display an error page with as much or as little information as you want. If it's a remote CFC call, however, it's extremely annoying for the remote developer to just get useless ColdFusion exceptions. Therefore I would always wrap every remote CFC method in its own try/catch, so if something goes wrong you can still return them something useful - even a "false" is better sometimes than an exception. You can then do what you like within the catch block - send you an email, log to disk, whatever.

    Just a few thoughts, haven't proof read them though so expect massive, glaring mistakes and poor advice.

    A
    Adam Cameron.
    Inspiring
    July 20, 2011

    I agree with Owain in almost all areas except what he says about web service calls.

    As a developer I'd much rather get an actual exception back from a web service than just some status code.  If I have an exception message, I have something I can use to work out what went wrong.  A message that simply amounts to "it didn't work" doesn't help anyone.  That said, I would try as much as possible to mask the inner workings of the web service from the caller, catching generic exceptions, and raising my own more usage-specific ones.  EG: rather than some JDBC exception telling me I've got a logic error in my SQL, I'd wrap that up with an exception saying there was a DB error, it was this code (from my own list of codes), and here's a bit of detail (the original exception's message value, or something).

    --

    Adam

    Owainnorth
    Owainnorth
    Inspiring
    July 20, 2011

    Yes sorry I worded that badly (and perhaps didn't make clear) - if someone needs to see an error, make sure they see it. All I meant was that I would try not to just throw an exception, but return something perhaps tidier and more useful.

    Most of my webservices now return XML or JSON, so you can build the error into the standard return object format without needing to change it. For example, the XML return object could have a "success" element. If it's true, a "messages" element which contains any info, if not it can contain details of the error.

    I've also taken (for internal systems) to making it very clear in the error messages whether it's something they've done wrong or whether it's something outside their control, so they know whether to try harder or send me an abusive email.

    I've worked with several APIs that just return "NO" when you've sent off some enormous XML-based request, and it really is not fun.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices