Hacker News Reader

Comment by ootachi | Hacker News Reader

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.

View on HN

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