Re:Why I’m not leaving Python for Go
by stcredzero on Monday September 24, 2012 @03:38AM
(#4563615)
> The default behavior for an error in a programing language with exceptions is to crash. This gets your program back to a known state (i.e. not running). It's impossible for code to blindly continue when something bad happens.
In Smalltalk, the default behavior for an error is pretty much business as usual, because exception handling is mostly just Smalltalk code running normally. In some Smalltalks, you can override the "top level handler" and ensure that an app never crashes. (An infinitely growing collection will exhaust heap and crash the program that way.)
I don't know about Go, but lint is commonly used to enforce checking of return values in C. Presumably Go could bake an option into the compiler to enforce this too.
In Go unused variables are an error, so you are forced to either handle errors or explicitly ignore them (by assigning them to _).
Sort of,
you can actually get away with invoking a function and not assigning its result at all
I think assigning the error to _ is only necassary when you have multiple return values(one of which is the error) and you are interested in at least one of them.
e.g.
returnsTwoValues() x := returnsTwoValues()maps are also interesting because
value := someMap[key] value, keyIsPresent := someMap[key]
If you want to handle some error in a way other than crashing, handle it. Web frameworks usually catch exceptions that arise while a request is being handled, finish the request, and keep handling new requests. You handle things more specifically only as needed.
I like that behavior so much more than having a program keep running in an unknown state unless you handle errors line by line (and value it more than keeping code execution where I can see it). I don't think my programming language knows what errors are very important, either — that depends way too much on context.