Hacker News Reader

Comment by julik | Hacker News Reader

In short: if you have a meaningful recovery pathway for a particular exception this can be useful, but I found that 9 out of 10 exceptions/errors in code cannot be recovered from.

This is checked exceptions all over again... Frankly, I usually do exactly the opposite. Most cases I've seen the exceptions that can arise are not widely known in advance, and for most spots where exceptions can be raised from I simply do not care about them as much either. If my DB is not accessible - do I really, really need to wrap it? If the DNS resolver is failing - do I really really need to wrap it?

When debugging I actually appreciate when a library/controller/module/whatnot does not attempt to "enhance" the exception from something outside of its control with a wrapper, and value seeing the original failure instead.

View on HN

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

Not that this invalidates your point in any way, but returning a 503 for database (or any other resource) unavailable is useful to disambiguate server errors from transient connectivity/database is temporarily unavailable errors.

> This is checked exceptions all over again...

That is an interesting topic, as I went through the cycle of adding and removing them, they always felt like the right thing, but they felt like "work". They make coding less fun, having to think through failure conditions, like you say, you don't care about.

I guess the answer is really there is no one sized fits all solution, we have some applications where the correct solution is to crash, we have other applications that can't crash under any condition. You just need to know where you are.

Edit:

Also, out of the box C++ checked exceptions implemented terribly.

http://www.gotw.ca/publications/mill22.htm

The (Mis)understanding section describes it pretty well.

"exception specifications" are deprecated since c++11 and completely removed in c++17 if I'm not mistaken.

Yes, it was that bad.

> I […] value seeing the original failure instead

This is what Python’s “raise from” is for; to preserve the original exception.

We primarily use custom exceptions to add detail to our error logs while still remaining concise. Generic exceptions are exceptionally useless for trying to debug issues, I've found.

Typed exceptions convey a bit of information to enable specialized handling at runtime, they are not meant to try and make debugging easier.

I'm not sure what you mean by "they're not meant to". They work, I don't care what they're "meant to" do. It also helps with general analysis of logs.

It's redundant.

The message (a string) will give you that information, nothing is lost by catching a base Exception and writing it to a log.

typed exceptions is about special handling. The type information allows the programming language to offer special handling when that is necessary, it is NOT meant to replace good error messages.

But it also isn't about taxonomy, which is something that a lot of people miss. It's putting the cart before the horse.

---

But you specifically talked about debugging. If you're talking about interacting with an attached debugger, the developer already has everything they need, there is no reason why specific, typed, exceptions are needed to assist that.

so you MUST be talking about general debugging by reading logs and the like, but those logs will tell you both the error message and the stack trace with the specific line that originally threw. Unless, of course, you're catching and rewrapping the exception and throwing that information away...

Reply on news.ycombinator.com