Comment by guidovranken | Hacker News Reader

Comment by guidovranken | Hacker News Reader

I don't write a lot of Go but I have fuzzed a reasonable amount of it. One of the most common types of bugs I encounter are slice out-of-bounds errors. In Go, this invariably leads to immediate program termination (panic). Especially parsers of serialized data received over the wire (like protobufs) are susceptible to slice OOB bugs because the programmer needs to reason about lengths, offsets and integer wraparounds, and this is often hard to get exactly right. Due to the combination of parsing untrusted data, the likelihood of bugs and flat-out crashes if there is a bug, network-facing Go software is especially prone to very low-effort denial-of-service attacks.

Python and Java got this right: everything throws an exception, including out-of-bounds access (IndexError, ArrayIndexOutOfBounds), so by wrapping your whole application in a try/except block you can eliminate a whole class of otherwise fatal errors.

Unless I missed something, the upcoming change isn't going to alter the handling of OOB's, which seems like a missed opportunity because a fully-fledged try/catch mechanism could effectively defuse many bugs.

Go already lets you recover from panics in a way similar to Java exceptions. For example, the standard library's HTTP server recovers from panics so if a request handler has an out-of-bound array access (or other panic-inducing error) the server continues serving other requests. It sounds like the programs you're fuzzing are missing an opportunity to be more robust.

The "try" proposal is about handling routine, expected errors.

In Java land checked exceptions are considered to be an anti pattern for sometime. If I remember correctly one of the major change in Hibernate ORM 3.0 was converting checked exceptions to runtime equivalents (ie, caller is free to disregard the exception) (this happened 10-12 yrs ago). Coming back to Golang, you get the same behaviour if you are not checking `error is nil` condition

> In Java land checked exceptions are considered to be an anti pattern for sometime.

It depends on whom you ask. Some people quite like checked exceptions. Either way, both checked and unchecked exceptions are superior to golang's approach to error handling.

Not sure what you mean by "free to disregard", but the exception being unchecked doesn't fundamentally alter the control flow of a thrown exception. It only affects type checking - hence the name.

When Java finally got generics, it didn't add any support for generic sum types of checked exceptions.

  stream.map(f).collect(…)

should obviously be able to throw anything f could throw. But instead f is forced to wrap every checked exception, and so pretty much everyone has given up and started declaring new exceptions as unchecked.

Reply on news.ycombinator.com