2

Wondering if anyone can explain the difference between errors and exception errors, or, more specifically, when one should use addError(errorMsg) instead of addError(exceptionError)?

The documentation is a little obtuse to me. I think it also is accidentally explaining the addError(errorMsg) method twice right now, which I'm finding a little confusing.

Don't they both just show an error in the application interface? In my particular case, I don't actually need anything to pop up in the UI, I just need to surface an error so that DataLoader knows why records fail if they fail. Not sure which to use.

1
  • The second addError listed in the doc is for adding the error message to a specific field. Feb 6 '19 at 18:48
4

If you're using try-catch, consider using addError(Exception) if you want to write smaller code[citation needed], and if you're not, use addError(String). In my experience, properly bulkified code will typically use addError(String).

The addError(Exception) method is typically used when you're writing atomic updates, usually within a Visualforce page, and the addError(String) method is more likely to be used in a trigger so it is properly bulkified (e.g. some records can succeed while others fail).

Both will result in an error being reported to the upper-level API, which might be a user saving a record, a Visualforce page, or an API-enabled tool like the Apex Data Loader. Both have the same general effect (the Data Loader will get an error in the errors*.csv file).

3
  • This is probably a comment for another thread, but I try to avoid try-catches because I don't really understand them?? I do try to properly bulkify whenever I can, getting better at it little by little. And I should have read this first, I just commented above about some succeeding while others fail - exactly what I want, no atomic for me please! Thanks for the explanation!
    – mlpSFadmin
    Sep 27 '17 at 18:34
  • @mlpSFadmin You're welcome! I do suggest you learn try-catch eventually, but avoid using it until absolutely necessary (there are times where it is required). In the majority of cases, you can avoid try-catch blocks using if statements (as demonstrated in this answer), but there are times where they are unavoidable. Unfortunately, this takes a bit of experience to get it "just right", but with a little practice/study, you'll quickly become a pro at it.
    – sfdcfox
    Sep 27 '17 at 18:40
  • Gtk. I used to use them more frequently (good ole "copy & paste from online" method of coding) until a software engineer friend pointed out they're pretty extreme in that they actual catch the error and stifle it, and should be used with caution. Been meaning to dig more to see what experienced developers had to say!
    – mlpSFadmin
    Sep 27 '17 at 18:50
4

The difference isn't apparent until you take a look further down on the documentation page you linked.

When you get to the detailed descriptions of each method, you'll see additional information in the "signature" section

addError(errorMsg)

Marks a record with a custom error message and prevents any DML operation from occurring.

Signature

public Void addError(String errorMsg)

vs

addError(exceptionError)

Marks a record with a custom error message and prevents any DML operation from occurring.

Signature

public Void addError(Exception exceptionError)

One method accepts a string, the other accepts an Exception (or a subtype thereof).

That said, that's probably about the only meaningful difference between the two methods. The concept of having multiple methods with the same name, but differing in the number and/or type of parameters they take is called "method overloading" (a type of "polymorphism", a term for a programming concept. The term is derived from Greek meaning "many forms").

The note about surfacing error messages in the application interface might cover more than just the UI (DataLoader is a different interface that interacts with the Salesforce "application"), though I don't see the term precisely defined anywhere in the apex docs.

At any rate, though, the behavior I think you're describing (using DataLoader, encounter an error, error pops up in Salesforce UI in your browser) does not happen. Error messages are only surfaced in the interface that initiated the work that encountered the error (you may get an email from Salesforce as well).

4
  • 2
    To be pedantic, "polymorphism" is more about Interfaces, and abstract and virtual classes, while a method by the same name with different parameters are called "overloaded methods".
    – sfdcfox
    Sep 27 '17 at 15:27
  • I don't actually need an error to pop up in the Salesforce UI at all, just in the errors file from DataLoader! Sorry if that wasn't particularly clear. And that makes sense that one accepts a String and the other...doesn't. What an "Exception" capital E is (or any of its subtypes) I think is the new part here that threw me. Sounds like String is the one I want!
    – mlpSFadmin
    Sep 27 '17 at 18:01
  • @mlpSFadmin That's what I was saying. If you're using DataLoader to operate on records, error messages you add via addError() will show up in the error file you get from DataLoader (and not in your web browser). Either method would work fine, but the variant that takes a String is probably the most appropriate here. The twitter version of explaining Exceptions would be "Exceptions are special errors (like dividing by 0) that causes your code to stop what it's doing to find out if it can continue or not."
    – Derek F
    Sep 27 '17 at 18:30
  • Ok that makes sense - the one other thing I don't want here is for all changes to be rolled back; if we're processing ~400 records, I want only the failed rows to fail and the rest to succeed. Not sure exactly if the Exception approach would try to roll back everything, but it felt like if either would, that one would, and should therefore be avoided.
    – mlpSFadmin
    Sep 27 '17 at 18:33

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.