> 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-A

> 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.