Away from Exceptions: Errors as Values

Throws is for checked exceptions. Unchecked are not listed in the throws list.

I agree that both exceptions and error values (aka result types) have their place. I would say that error values are good for when a caller should explicitly handle that case, and that exceptions are good for errors that a caller should not be expected to handle explicitly. A lot of times this breaks down as meaningful application errors vs operational or programming errors. I am struggling to find the right words for this, so I can give an example:

Let's say we have a function used to register a new user account on a site like HN.

An error value would be appropriate to return when the username is already taken, so that we can express to the caller that this is a possibility that must be handled. Most likely the caller would want to tell the user. A maintainer doesn't really care when this occurs, since it's part of the application's healthy behaviour.

An exception would be appropriate if the database is unavailable. The caller would not be expected to tell this to the user, nor is there any logical way for the caller to react to this situation specifically. In this example of a web app, the best course of action is likely returning a generic "unexpected error" message and/or a HTTP 500. The caller can typically let the exception propagate to the web layer's top level exception handler where it will be logged. As a maintainer of the system, a stacktrace is valuable for pinpointing the problem with the code path that lead to it.

(Checked exceptions, where available, blur these lines a bit)

---

In the Java world... (stop reading if you don't care about Java) ...it has been increasingly common to see types like Result used for error values. Recently, there have also been additions to the language that make errors-as-values more practical. Sealed classes (a preview feature in Java 16, and a full feature in the soon-to-be-release Java 17) are basically an implementation of product types (with a characteristically verbose Java-ey syntax) that could be used to implement results. Returning to our example with this:

    sealed interface RegistrationResult {
          record Registered(Account newAccount) implements RegistrationResult { }
          record UsernameTaken() implements RegistrationResult { }
          ... 
    }

https://openjdk.java.net/jeps/409

beyond Java 17, you will be able to pattern-match over these with exhaustiveness enforced by the compiler. It will look something like:

    switch(registrationResult) {
            case Registered(Account newAccount) -> ...;
            case UserNameTaken() -> ... ;
            ...
    }

https://openjdk.java.net/jeps/405

I am writing some C++ code for a web application, and there I am handling errors via exception. There are two broad types of exceptions, one that is internal and one that needs to be reported to the user. Following is how I an handling the errors, please could you all suggest a better approach if my approach is sub-optimal designwise?

// Base class

    HandleRequest(req, res)
    {
        try {
            try {
                post_processing(req, res) // implemented by derived class
                process_request(req, res) // implemented by derived class
                pre_processing(req, res) // implemented by derived class
            } catch(send_to_user_exception) {
                send_error_to_user(send_to_user_exception.what()) // implemented by derived class
            }
        } catch(internal_exception) {
            log_error(internal_exception.what())
            send_internal_error_to_user(internal_exception.what()) // implemented by derived class
        } catch(unknown_exception) {
            log_error(unkown_exception.what())
            send_internal_error_to_user(unkown_exception.what()) // implemented by derived class
        }
    }

// Each request type is handled by its corresponding derived class and implements the following methods of the base class.

post_processing(req, res) // will throw exceptions of type send_to_user_exception and internal_exception

process_request(req, res) // will throw exceptions of type send_to_user_exception and internal_exception

pre_processing(req, res) // will throw exceptions of type send_to_user_exception and internal_exception

send_error_to_user(error)

send_internal_error_to_user(error)

> This hasn't turned me off of monadic error handling, but it has made me think of it as FP's version of exceptions, rather than an upgrade.

This reminds me a lot of Java's checked exceptions just with different window dressing. You move the failure mode type information from the exceptions list ("throws" clause) into the return type.

Typed error return values is definitely an improvement in ergonomics over C-style error code returns, and pattern matching is definitely a big improvement on ergonomics too, but I think error handling has a problem of fundamentally irreducible complexity. For example, if you make network calls, you have to be prepared for network calls to fail, and you have to design your system to recover from it somehow, whether that happens in a try/catch or a match on Either[Throwable, Result].

There's nothing wrong design-wise with your approach, IMO. I've seen several people (including very well-known C++ personalities) argue that exceptions should be used for X and error codes for Y, but this is just convention.

C++-wise, you probably want to catch std::exception and "..." too.

Finally, you said that there's two types of exceptions and only one of them is supposed to be reported to the user, but in your code you seem to report everything to the user. You should edit your message to clarify what you meant.