3 ms·

I've heard people complain about the explicit error handling in go, but that is mostly because they are coming from other languages such as java which have infe

I've heard people complain about the explicit error handling in go, but that is mostly because they are coming from other languages such as java which have inferior error handling that lets them write 'neater' code, but which generally results in less than robust error handling. Picking on Java, it has checked exceptions, unchecked exceptions, and errors. It's basically a minefield of complexity leading to undefined behavior and/or misbehaving error legs. I can't tell you how many times I've seen InterruptedException mishandled, Throwable (which includes VirtualMachineError) caught with no appropriate handling (quick - what is the appropriate handling of a VirtualMachineError?), or exceptions allowed to wildly propagate.

kjeetgill 7y ago
> java which have inferior error handling that lets them write 'neater' code, but which generally results in less than robust error handling Wowza, that's a strong stance. Look, I'm a fan of Go and Java is definitely aged in a lot of places but this is one of the most bizarre claims I've seen. Criticism of Java's exceptions come from both sides, some people who hate unchecked exceptions so "anything can throw" (same reason C++ camp often avoids exceptions); or that checked exceptions are stupid since you can't meaningfully fix Interruptions or IOExceptions so it's verbose and meaningless to force local catches; they almost always need a rethrow. Both of these criticism are fair because in the end they both make sense sometimes and thus are misused for one another occasionally. We'd all like one answer consistently applied but we don't have it here. Error codes formalized as a part of an API have their place but I find their utility is much more niche than people give them credit for. Why should I decode error codes when a String and a Trace will do? Hint: only when errors have formal semantics such as within a protocol. How I handle the error is partially decided by spec. But to say that in comparison to Go? Go has its normal err mechanism and panic/recover. err is a huge step up from C style errno/manual checking. In practice, Go's err is embarrassingly used just like a checked exceptions: observe and ignore/log or propagate. You end up just unwinding the stack manually, losing the trace, maybe adding context occasionally, like 70% of the time. You handle it where it's meant to eventually, sure. Like everybody does, when it is done right. panic/recover is just unchecked exceptions all over again anyway. They seem to be treated as voodoo idiomatically, sure, but they're there. Go is a great language that brought some really good language runtime features together in a pretty tidy package. Besides maybe defer, which is pretty clean, error handling just isn't a part of the language that got the polish that other parts of the language got on the first pass.
apta 7y ago
> which have inferior error handling that lets them write 'neater' code, but which generally results in less than robust error handling. Error handling in languages with exceptions is (1) more robust, as you actually have to make an effort and explicitly ignore exceptions, and not just accidentally forget to handle them or overwrite them as with golang. (2) you don't have to incur a branch for every error check, which should result in faster code in the non-exceptional case. (3) the code reads easier and clearer, especially where you have to chain calls, which in golang will take up much more code. (4) Exceptions are concrete types, and give you a stack trace automatically, unlike golang where errors are mostly strings and if you need any context you have to manually populate it.

kjeetgill 7y ago

> java which have inferior error handling that lets them write 'neater' code, but which generally results in less than robust error handling Wowza, that's a strong stance. Look, I'm a fan of Go and Java is definitely aged in a lot of places but this is one of the most bizarre claims I've seen. Criticism of Java's exceptions come from both sides, some people who hate unchecked exceptions so "anything can throw" (same reason C++ camp often avoids exceptions); or that checked exceptions are stupid since you can't meaningfully fix Interruptions or IOExceptions so it's verbose and meaningless to force local catches; they almost always need a rethrow. Both of these criticism are fair because in the end they both make sense sometimes and thus are misused for one another occasionally. We'd all like one answer consistently applied but we don't have it here. Error codes formalized as a part of an API have their place but I find their utility is much more niche than people give them credit for. Why should I decode error codes when a String and a Trace will do? Hint: only when errors have formal semantics such as within a protocol. How I handle the error is partially decided by spec. But to say that in comparison to Go? Go has its normal err mechanism and panic/recover. err is a huge step up from C style errno/manual checking. In practice, Go's err is embarrassingly used just like a checked exceptions: observe and ignore/log or propagate. You end up just unwinding the stack manually, losing the trace, maybe adding context occasionally, like 70% of the time. You handle it where it's meant to eventually, sure. Like everybody does, when it is done right. panic/recover is just unchecked exceptions all over again anyway. They seem to be treated as voodoo idiomatically, sure, but they're there. Go is a great language that brought some really good language runtime features together in a pretty tidy package. Besides maybe defer, which is pretty clean, error handling just isn't a part of the language that got the polish that other parts of the language got on the first pass.

apta 7y ago

> which have inferior error handling that lets them write 'neater' code, but which generally results in less than robust error handling. Error handling in languages with exceptions is (1) more robust, as you actually have to make an effort and explicitly ignore exceptions, and not just accidentally forget to handle them or overwrite them as with golang. (2) you don't have to incur a branch for every error check, which should result in faster code in the non-exceptional case. (3) the code reads easier and clearer, especially where you have to chain calls, which in golang will take up much more code. (4) Exceptions are concrete types, and give you a stack trace automatically, unlike golang where errors are mostly strings and if you need any context you have to manually populate it.