| Go's errors were a response to exceptions in Java. Java exceptions failed in several key ways: 1) exception catch sections had no lexical access to variables declared inside the try {} block. This was papered over a bit with some resource auto-closing syntax, but fundamentally an error handling section of code should be able to introspect the state of variables in the processing where the error occurred. YES you can move the variable declarations out of the try {} block but that is an annoyance, especially if you are expanding error handling to be robust, you must constantly move more and more local variables out of the block that they lexically and semantically belong to. 2) the try {} block imposes a big cost to casual error handling on a method invocation: it will force an indentation (which consumes precious horizontal real estate and may force excessive breakup of what should be a compact set of processing to more sub-functions), it involves a visually polluting keyword with the catch sections. Some syntax like sortMyJunk()
:EXCEPTION IndexOverflowException ? handleOverflowError()
:EXCEPTION OutOfMemoryError ? sendPionToMicrocenter()
would have been really nice in java, it would have enabled more compact code that emphasizes the mainline processing, while visually placing the hopefully less common error processing off to the left or to an indentation.try {} should have been reserved (along with #1) for truly complicated exception flow handling. Perhaps Visual Basic had good ideas with error handling blocks occurring after labels, although my recollection and experience with VB wasn't deep: I don't remember if onError blocks had lexical access to local variable state. |