3 ms·

Except that every nil pointer dereference panics. Every out of bounds access panics. Is that also prevented by culture? Let's not forget that, for better or wo

Except that every nil pointer dereference panics. Every out of bounds access panics. Is that also prevented by culture? Let's not forget that, for better or worse, exceptions in Java are checked. The types of exceptions that are errors in Go, must be explicitly handled or forwarded by the caller in Java - there is no way around it. The the type of exceptions that are panics in Go are just unchecked exceptions in Java: you don't have to explicitly handle them, but you can use the same mechanism for doing so, and handling them is more graceful, easier and culturally enforced than panic/recover. I have many criticisms of Java, but I'd argue Java culture is much more graceful in error handling there.

zemo 5y ago
out of bounds panics aren’t all that common in practice. Yeah they’re easy to write, but usually if you have a slice you’re going to range over the whole thing or loop over it up to its length anyway. It’s not common to handle slice indexes on their own and keep them hanging around outside of the context of a for loop. The major exception to this is cases where you want the first element of a slice and didn’t check that the slice is non-empty first, which sucks. But in any case, it doesn’t come up all that often in production code. You can range over a nil slice or a slice of zero items safely. Nil pointer dereferences are way more common, as is assignment into a nil map. Those I see coming up a lot in newer Go programmers’ code.