1

I've been developing some large, complex pages with lots of action functions, and I find myself writing a ton of boilerplate.

Since I'm developing for Force.com Sites, any uncaught error appears to crash the app from the end-user experience. There are many places where there shouldn't be errors, but we end up having unexpected problems, and therefore we have last-resort error catching for anything that falls through the cracks. It looks a lot like this:

public PageReference doSomething () {
    // Verify inputs and display errors to users

    // Do the work
    try {
        doTheRealWorkWithRelevantErrorCatching();
    } catch (Exception e) {
        // Catch anything that fell through the cracks
        ApexPages.addMessage(new ApexPages.Message(ApexPages.Severity.ERROR,
            'There was an error: ' + e.getMessage());
        return null;
    }
}

I find that I'm adding that try...catch boilerplate to almost every actionFunction I define. It makes me wish that Apex supported decorators so I could write it once and do this:

@reportAllExceptions
public PageReference doSomething () {
    // Verify inputs and display errors to users

    // Do the work
    doTheRealWorkWithRelevantErrorCatching();
}

Short of that, are there other strategies or best practices to ensure that throughout my app, I'm catching all possible exceptions and displaying them to the user, rather than allowing a crash?

1

Your first line of defense should be test methods. Test methods that use a generous number of asserts to test border logic tests should keep your code fairly stable. The unauthorized page message, while frustrating, is actually a security mechanism, and circumventing that security through liberal exception handling is actually a security risk. For example, if a user causes a particular crash based on some input, the error might give them enough information to manipulate the code into exposing or manipulating data in ways that the user shouldn't be able to do. Strengthen your test methods, and test Unauthorized messages by testing using an inside user with permissions similar to the site's permissions. Also, you can choose to replace the standard Unauthorized page with one of your choosing. That might be preferable to exposing an error that might provide attack vectors.

  • I see your point, and understand this approach. My goal isn't to expose the specifics and details of crashes; rather, we have some pages critical enough that there is a requirement that they not crash. The error message displayed could be completely generic ("An error has occurred - Please contact support") but I need to catch all errors and display as ApexPages.Messages, rather than allowing the page to crash and display our custom error page, which leaves me with the boilerplate as above. Does that clarification make sense? – Benj Sep 30 '13 at 13:05
  • Certainly does. There's no hard and fast rule for what is definitely the best practice, from what I've seen, but the general guideline is to avoid exposing any more data than necessary for clients to know there's something wrong. – sfdcfox Sep 30 '13 at 16:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.