I have a different requirement in which I want to store all exceptions that occurred through out the application in a custom object. What is preferred way of doing that and what fields should be there? Has anybody done something like that in past? Share your thoughts
1
-
2Not sure if your creating a managed package (hence the comment). But you can define an Apex Exception user when setting up the package. Salesforce will then route any unhandled exceptions that occuring in orgs where you package is instaleld via email. There is pretty cool idea here for routing these into your own production org for further analysis. developer.force.com/cookbook/recipe/…– Andrew FawcettApr 2, 2013 at 8:59
Add a comment
|
2 Answers
Peter's notes are spot on about being careful about governor limits and transactions, but I personally have found many other cases where it's desired to catch an exception and log it to a database table and then show the user a friendly error (or occasionally just be silent about the exception).
It's a good idea to create a standard utility class with methods that handle the standard stuff for you. Something like this is useful:
public static void logError(Exception e, String msg)
which logs the full Exception stack trace to a long text area, another long text for the (optional) message that can contain things like the object that caused the error, and a User lookup field to log the user who encountered the error.
To avoid logging thousands of records if you have a high-volume environment, you may want to add an additional check that you don't log more than N exceptions from the same code origin per day.
This can only be accomplished in a limited capacity.
Because Apex executes in an atomic transaction, anything that causes that transaction to fail will also roll-back saves being made to your custom object. There are two big offenders: Governor limit exceptions and DML exceptions. When you write a validation rule, or you wish to block a save with a trigger using sObject.addError(), those are causing DMLException to be thrown, which then blocks the transaction.
If you then catch DMLException in those instances and don't rethrow an exception, you will sidestepping your own validations. You could work around this, perhaps, but it becomes very troublesome.
Governor Limit exceptions are uncatchable. And so, nothing to be done there, but you'll get an email anyway.
For other exceptions, however, you could implement an object with a long text field to store information collected along the way and simply write to it when you reach a catch block.
