How to correctly extend runtime exception?

Question

We have a GraphQL server which sends data to the front end client. We have other tenants who will use our sever and host their code. I want to create a system where they all can create any custom exceptions if they want or they can use some of the exceptions that the server can provide like DependencyFailure. Also error code and isRetryable should be sent to clients.

For this I was thinking I can extend runtime exception (and add some common fields like isRetryable and error code). Will call this BaseException. This will have many constructors with all param combinations: message, retryable, error code, throwable cause.

Now I don't understand how to implement DependencyFailure (and other server provided exceptions). Should it have the parameters like error code and isRetryable customisable by tenants? What if a tenant wants to throw DependencyFailure but make it retryable? If I make it customisable there won't be any difference between BaseException and DependencyFailureException.

Answer 1

Your approach of creating a BaseException with common fields like isRetryable and errorCode seems reasonable. However, for server-provided exceptions like DependencyFailure, it's important to strike a balance between customization and maintaining distinction.

Consider allowing tenants to customize certain aspects of server-provided exceptions, but with predefined customization options. For example, provide a set of flags or options that tenants can choose from to modify the behavior of the exception. This way, there's still a clear distinction between exceptions created by tenants and those provided by the server.

If a tenant wants to make a DependencyFailure retryable, they can choose the predefined option for making it retryable rather than having full customization. This ensures that the core characteristics of server-provided exceptions remain consistent across tenants while allowing some flexibility.

By providing a limited set of customization options for server exceptions, you maintain clarity and prevent the overlap that could make it difficult to differentiate between a generic exception and one specifically defined by the server.