System.assert() in production code? (vs. custom exception)

Question

It's come to my attention that you can use System.assert(), System.assertEquals(), etc. outside of test classes in Apex.

I've seen a lot of custom Exception classes written that do nothing but extend the Exception class, and a lot of Apex production (i.e. non-test) code that looks more or less like this:

public class MyClass {

  public class MyException extends Exception {}

  public static Account getAccount(Id accountId) {
    List<Account> accounts = 
      [SELECT Name FROM Account WHERE Id = :accountId];
    if (accounts.size() != 1) {
      throw new MyException(
        'Did not find an account for Id ' + accountId
      );
    }
    // ...
  }
}

This is less code, and cleaner in my opinion:

public class MyClass {

  public static Account getAccount(Id accountId) {
    List<Account> accounts = 
      [SELECT Name FROM Account WHERE Id = :accountId];
    System.assertEquals(
      1, 
      accounts.size(), 
      'Did not find an account for Id ' + accountId
    );
    // ...
  }
}

I know the below approach is going to throw an AssertException, whereas you can give the exception whatever name you want in the above approach. But the name of the exception class itself seems pretty unimportant -- way less important than the message, which you can customize either way.

Are there any other drawbacks to the System.assert... approach that I'm neglecting?

Answer 1

Outside of absuing the functionality a little...

• Using system.assert() doesn't really save much in terms of typing or lines of code (5 lines vs 6 lines in your example, counting the lines with closing braces/parens)
• Only works well for relatively simple comparisons (it's not going to be making a long or highly nested set of conditions any shorter)
• Would prevent you from being able to have multiple catch blocks to distinguish between different exception types (you aren't doing the pokemon catch, catch(Exception e), i.e. gotta catch 'em all, are you?)
• Doesn't contain the name of the class unless you look at the stack trace (which needs to be fetched using .getStackTraceString())

I think that having the exception name is worth a bit more than you give it credit for. In the email you (or someone) would get, or in the log, a good exception class name can immediately tell you which class to start digging into without needing to look for the stack trace.

Answer 2

Don't do this...

The System.assert methods throw fatal exceptions which cannot be caught!

public class MyException extends Exception {}

try{
  system.assertEquals(true, false, 'false != true');
}catch(Exception e){
   throw new MyException('Something went wrong!');
}

Result: System.AssertException: Assertion Failed: false != true: Expected: true, Actual: false

This breaks control-flow for any callers of your code. IMO, it's a serious anti-pattern that should be avoided.