Code Design Decision – Always throw custom exceptions

> If my DB is not accessible - do I really, really need to wrap it?

I would say yes. Most of your code doesn't care that the database failed with a PG-300292-AB error. What you do care about is that there is a system failure. If you wrap your system failure, and document it as THE exception, the API caller will know what to look for.

In general there really are only a few exceptions: system, invalid input, non found. I'm probably missing one or two others. Most exceptions/errors are one of these. If you make these 3-5 exceptions/errors explicit, you're APIs will be pretty clear. A function can pretty much always returns a system exception (bad IO, sunspots, etc.). It can also throw an invalid input exception. Your client can handle these cases differently. For a HTTP RPC service, you return a 500 for system and 400 or 422 in the example. Not bad.

One can even wrap the exception with a more detailed message (which I know you said you didn't like) that preserves flow. So you get a invalid input exception, you can add details around the null value by properly nesting the messages. They should show up in your logs.

This is one of the problems with checked exceptions. The library author is in no position to expect me to handle an exception. Whether or not I can relies on the design of my system, which they have no window into.

This idea can also be explored in the Go programming language. Go has an error type, not exceptions, but error checking famously can be rather verbose.

Two cases to consider come to mind. First, the common pattern

    result, err := SomeFunc()
    if err != nil {
            return err
    }

Here the code is just passing along the error to the caller, unchanged.

Second, signaling errors ab initio

    result := // some calculation or behavior
    if result != expected
    return fmt.Errorf("An error happened. Expected %v, go %v", expected, result)

In the first case, the discussions around whether or not to throw custom exceptions applies analogously: should you wrap the error or not?

The second case, I argue, is always wrong. The error is "stringly typed", and can be examined and read by a person, but that's it. The correct way is to define an error type meaningful for the context. Errors in Go are type implementing the error interface

    type error interface {
            Error() string
    }

therefore, an error should be a type relevant or the context. A useful starting point looks something like

    type DomainError struct {
            Code DomainErrorCode
            Message string
            Details []DomainType
    }

    func (d DomainError) Error() string {
           return Message
    }

then code can look like

    // some work
    if result != expected {
            return DomainError {
                Status: AnErrorCode
                Message: fmt.Sprintf("Error %v. Expected %v, go %v", AnErrorCode expected, result)
                Details: []DomainType{ expected, result }
            }
    }

And the caller gets back a type providing useful information.

"Just because it's useful to wrap exceptions in 5% of the cases doesn't mean you should wrap the rest 95% just in case"

Yes you should wrap ALL third party exceptions for the reasons given in the post. There is no 'just in case' reason. Any third party exception returned may cause your client to be dependent on it.

> You don't know which exceptions will be raised in advance.

> Most of exceptions are unrecoverable (that's why they are called exceptions), the best course of action is to crash, which happens by default.

I prefer to propagate such unknown exceptions to a top-level catch to clanly log that something happened.

I usually have two types of exceptions: the ones I expect at some point (a HTTP call failing for some reason) that I may ("when I have time") group in "known exceptions we should not worry about" and log them as "informational", and exceptions I did not anticipate that I want to log as well, but with a critical level because they were, well, unexpected.

So crashing right when they happen may not be the best strategy.