5 ms·

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, t

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.

tech_dreamer 7y ago
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
- apta 7y ago
  > 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.
- bmm6o 7y ago
  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.
- erik_seaberg 7y ago
  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.
agwa 7y ago
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.

tech_dreamer 7y ago

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

apta 7y ago
> 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.
bmm6o 7y ago
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.
erik_seaberg 7y ago
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.

agwa 7y ago

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.