Hacker News Reader

Comment by luriel | Hacker News Reader

If panic/recover is the same as exceptions, why does everyone whine about the lack of exceptions?

The fact is that while in theory panic/recover are mostly equivalent to exceptions, in practice they are very, very different. Panic is only used in truly extreme situations (like running out of memory) or programmer errors, and you can pretty much write code ignoring it.

Most programs at most will need to call recover() once. Compare this with how exceptions are used in most languages where they are a fundamental aspect of a library's API.

Also the way defer() reliably and cleanly handles cleanup is much more pleasant than exception and 'finally'.

As for C macros, good C programmers have known for a long time that they are best avoided as much as possible.

View on HN

Because panic/recover are bad exceptions (recover can't specify the types of the exceptions it wants to recover from), and the libraries don't use them. Having to check errors is annoying since most of the time you want to bubble the error up to your caller. This is exactly what exceptions (or the error monad) do for you. In Go you have to do it manually.

Anyway, Go does have exceptions. It just doesn't make much use of them. Seems a shame to not use a useful feature, but oh well.

defer is not reliable if you forget to call it. RAII is much more foolproof than defer in this way. You can forget to call defer, but you can't easily forget to call the destructor.

>* Having to check errors is annoying since most of the time you want to bubble the error up to your caller.*

No, most of the time I don't.

What do you do then?

If the answer is "panic", note that exceptions are superior here, since exceptions let you "panic" without having to litter your code with those calls.

If the answer is some form of "log an error message", exceptions are superior, since you can group multiple related calls into one try-catch block and avoid having to check at the site of each and every call.

If the answer is some form of "return a different error code to your caller", exceptions are superior, because you can catch many different types of exceptions in one try-catch block and re-throw a different exception.

>If the answer is "panic", note that exceptions are superior here, since exceptions let you "panic" without having to litter your code with those calls. If the answer is some form of "log an error message", exceptions are superior, since you can group multiple related calls into one try-catch block and avoid having to check at the site of each and every call. If the answer is some form of "return a different error code to your caller", exceptions are superior, because you can catch many different types of exceptions in one try-catch block and re-throw a different exception.

How about locally handling the problem --which could be some non-issue-- and continue without the OVERHEAD of an Exception?

How about now using the verbose and convoluted try-catch-finally idiom for common and not at all exceptional error conditions?

How about THINKING about the error handling, instead of blindly catching "many different types of exceptions in one try-catch block and re-throw a different exception", which we've known for Java to result in a mess...

How about avoiding the exception stack penalty that happens when you "group multiple related calls into one try-catch block and avoid having to check at the site of each and every call" to merely log errors?

Reply on news.ycombinator.com