Custom Exceptions -- How does SFDC get it done in the back end?

Question

Suppose I have the following Class:

public class Yup{

    public class YupException extends Exception{}//END YupException

    public static void debugTestException(){
        YupException TestException=new YupException('This is only a test.');

        system.debug(system.LoggingLevel.ERROR,'TestException                       = '+TestException                       );
        system.debug(system.LoggingLevel.ERROR,'TestException.getCause()            = '+TestException.getCause()            );
        system.debug(system.LoggingLevel.ERROR,'TestException.getMessage()          = '+TestException.getMessage()          );
        system.debug(system.LoggingLevel.ERROR,'TestException.getTypeName()         = '+TestException.getTypeName()         );
        system.debug(system.LoggingLevel.ERROR,'TestException.getStackTraceString() = '+TestException.getStackTraceString() );
        system.debug(system.LoggingLevel.ERROR,'TestException.getLineNumber()       = '+TestException.getLineNumber()       );
    }//END DebugTestException()

}//END Yup

and execute the following code anonymously:

Yup.debugTestException();

I get:

1. How does new YupException('This is only a test.'); compile without having the constructor public YupException(string ErrorMessage){ ... }?
2. Similarly, how does YupException compile when I haven't implemented any of the methods mention in Yup.debugTestException()?
3. How do those unwritten methods and constructor actually execute / How do I get away implementing an Interface while not implementing any of it's methods let alone call an undefined constructor??

---

Here's primary documentation from Salesforce, but what does SFDC do on the backend that makes my inner-compiler-alarm go off?

• Lesson 5: Creating Custom Exceptions

• Exception Class

Answer 1

An exception is a virtual class, I would assume, given that it can be extended. From the documentation for extending a class:

A class that extends another class inherits all the methods and properties of the extended class. In addition, the extending class can override the existing virtual methods by using the override keyword in the method definition. Overriding a virtual method allows you to provide a different implementation for an existing method. This means that the behavior of a particular method is different based on the object you’re calling it on. This is referred to as polymorphism.

What I take from that is that you can use all of the methods from the Exception class, in addition to what you want to add-on by override. To answer your questions, it compiles and executes because Exception has a constructor and its own methods that are already wired up to Salesforce error handling.

Answer 2

How does new YupException('This is only a test.'); compile without having the constructor public YupException(string ErrorMessage){ ... }?

Similarly, how does YupException compile when I haven't implemented any of the methods mention in Yup.debugTestException()?

All those methods are part of the Exception class:

global abstract class Exception {
    global Exception() {
        // implementation
    }
    
    global Exception(String message) {
        this();
        // implementation
    }
    
    global String getCause() {
        // implementation
    }

    global String getMessage() {
        // implementation
    }

    global String getTypeName() {
        // implementation
    }

    global String getStackTraceString() {
        // implementation
    }

    global Integer getLineNumber() {
    
    }
}

We can almost safely assume that the Exception class is abstract, because it can't be constructed despite having global constructors (although, that could just be a compiler-enforced limit).

When you extend any Exception, your class automatically inherits all of its members, functions, and constructors, which is why your "do-nothing" class actually does quite a bit without any work on your part.

How do those unwritten methods and constructor actually execute / How do I get away implementing an Interface while not implementing any of it's methods let alone call an undefined constructor??

You're not "implementing", you're "extending". Implementation is for interfaces, which an Exception is not. Extending is for classes, and is how one class takes on the properties of another while being able to have its own additional properties.

Here's primary documentation from Salesforce, but what does SFDC do on the backend that makes my inner-compiler-alarm go off?

There's really nothing magical about this design. Think of it as a closed-source library that you only have a symbol-table for. You can extend the classes and call the stock methods, but you can't override them or examine them.