6

I have read the documentation and searched but can't seem to find an answer to this.

I am creating a method for portal, I need to pass any errors back to the front end portal in a way that the front end designer can present them to the user in a way the user will understand (instead of the raw error message).

I want to map friendly messages to the common exceptions we might expect to get. But short of causing the code to error and reading the message I can't find a way to find all possible messages.

Is there not somewhere a reference of all possible errors? I can find how to catch say DML errors, but I can't find any reference of what all the possible return messages might be.

Does such a thing exist?

8

There's two categories of exceptions: normal exceptions and DML exceptions. The Exception class outlines all the possible code exceptions you can expect, with short descriptions of each, while Core Data Types/StatusCode describes all the possible DmlException StatusCode values you might encounter. I'm not going to paste all of the possible values in to this answer, as those messages tend to change on a fairly frequent basis.

Just know that the Exception class in the Apex Code Developer's Guide shows all the possible non-DML exceptions, like NullPointerException and TypeException, while the SOAP API Developer's Guide contains a list of DML-related exceptions. It's probably not worth converting non-DML exceptions to "friendly messages," because they represent things that a developer would be concerned about, not messages that you'd expect the average user to understand.

|improve this answer|||||
  • I hate to even ask as I feel weird even questioning you lol but Why are you grouping, for example, AsyncException and CalloutException, under "normal" and DML under its own category? Are they all not essentially their own category? – Eric Sep 13 '16 at 21:29
  • 3
    @Eric I consider them different because they're documented differently. For example, you'll notice there's no RequiredFieldMissingException, or ValidationRuleViolatedException; they're all lumped in to a single DmlException, which can house multiple "exceptions" within it. Most of the other exceptions are singular in purpose, or very nearly so. Plus, DmlException is the only exception that actually requires going to a completely different manual to determine the possible errors that can occur. Not everyone makes that distinction, but I feel it's clearer to me. – sfdcfox Sep 13 '16 at 21:51
  • Plus an infinite number of possible extensions. – Adrian Larson Sep 13 '16 at 23:28
4

Here they are:

AsyncException
CalloutException
DmlException
EmailException
ExternalObjectException
InvalidParameterValueException
LimitException
JSONException
ListException
MathException
NoAccessException
NoDataFoundException
NoSuchElementException
NullPointerException
QueryException
RequiredFeatureMissing
SearchException
SecurityException
SerializationException
SObjectException
StringException
TypeException
VisualforceException
XmlException

Source is here.

|improve this answer|||||
3

There are many built-in Exception classes, and they are documented in quite a few locations, as noted by Caspar and sfdcfox. If you think catching all built-in Exception classes covers the gammut, however, you are sorely mistaken, as there are innumerable custom extensions to the Exception class, depending on the context org. In practice, this means that covering all the built-in types is not a comprehensive approach.

public MyCustomUndocumentedException extends Exception { }
|improve this answer|||||
  • Yes, at some point you'd have to have handler for the base Exception class and a generic message at the end of the try/catch sequence. In some ways I question the need to present the message nicely to the user - something happened that wasn't supposed to, there's no sugar-coating it. – Caspar Harmer Sep 14 '16 at 4:58
  • Well the issue is that the user is going to be on a portal page inputting data into a form. So if they manage to get an exception we need to give them a friendly message as to how to correct the data. Obviously front end validation SHOULD catch everything, but I like to cover all possibilities. – ScottH7a9 Sep 14 '16 at 13:20
1

One exception not mentioned yet is System.AssertException() which is fatal (and thus cannot be caught in a catch block).

You won't see this normally unless you're using System.assert() in your code but it is worth noting. It can be good practice to use these in production code, and if you're working with code written by someone else then you may encounter them.

Obviously, though, you are most likely to find them in test classes!

|improve this answer|||||

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.