Hacker News Reader

Comment by pswenson | Hacker News Reader

Didn't we try error codes back in the day? I think exceptions are brilliant. They let you write your error code in one place (at the top of the stack), instead of planning for every contingency at every level.

Once I discovered exceptions back in the 90s, life got a lot easier.

Of course Java ruined exceptions with the invention of the CheckedException, maybe this tainted the Go designers' thinking?

View on HN

The designers of Go rejected exceptions because, while seemingly simple, they are exceptionally hard to do correctly, and worse, it is extremely hard and subtle to distinguish between code that reasons about them correctly and code that does not.

Raymond Chen has a good break-down of the problem here: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

As someone that grew up with exceptions, I like the idea of errors being recoverable by default. If it's not fatal, your catch block is going to swallow the exception anyway. And if your error is, panic().

(This could be Java experience scarring my then-young mind)

Most exceptions aren't recoverable. They are usually a result of bugs or system problems. This means 1) the bug needs to be fixed. 2) the system needs to be fixed (start up a DB service, clean disk-space, add memory, etc).

This is where java went wrong, java checked exceptions treats everything as recoverable when recovery is unlikely.

I mean, someone tries to login to a web site and the DB is down. What do you do? Or there is a bug that throws a null pointer exception. How do you recover from that?

I think the error code approach has the same effect as CheckedExceptions. People will tend to code to ignore the problems and not report them. Exceptions are great in that they bubble up to the top of the stack, so they are easy to report/alert on.

Reply on news.ycombinator.com