4 ms·

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 im

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. 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.

dmpk2k 14y ago
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.
- luriel 14y ago
  In Go unused variables are an error, so you are forced to either handle errors or explicitly ignore them (by assigning them to _).
  - Djehngo 14y ago
    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() is legal x := returnsTwoValues() is not maps are also interesting because value := someMap[key] is valid and value, keyIsPresent := someMap[key] is also valid.
stcredzero 14y ago
> 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.)

dmpk2k 14y ago

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.

luriel 14y ago
In Go unused variables are an error, so you are forced to either handle errors or explicitly ignore them (by assigning them to _).
- Djehngo 14y ago
  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() is legal x := returnsTwoValues() is not maps are also interesting because value := someMap[key] is valid and value, keyIsPresent := someMap[key] is also valid.

stcredzero 14y ago

> 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.)