3 ms·

Hard disagree here. Instead of one type of error handling, there are two: panics and err. Panics could effectively be replaced with os.Exit() if you really wa

by bb88 2y ago

Hard disagree here. Instead of one type of error handling, there are two: panics and err. Panics could effectively be replaced with os.Exit() if you really wanted to exit. If anyone says Go is Great without addressing this issue, they've drunk the koolaid.

jitl 2y ago
panic/recover is good and necessary to have, Rust also has this. Swift’s fatalError is not recoverable which is very frustrating. I don’t like go much - languages that can have nil pointer errors can take a hike, but what I like even less than a nil pointer error while handling a request, is for my whole process to die unrecoverably because someone forgot to check a nil in an infrequently called API. Or when comparing something that’s not allowed to be compared. Like the language would be better if these mistakes were impossible to make, but as long as we have a language with a plethora of garden variety syntax can panic like `a.b` or `a == b` we should be able to mitigate that risk at runtime.
- bb88 2y ago
  In golang, `panic()` and `return err` are two different ways of unwinding the stack. 80% of my error handling in go is `return nil, err`. But there's no reason syntactic sugar couldn't be applied for something like `when err { return nil, err} { err := doSomething() }`
Cthulhu_ 2y ago
I think this is an unneccesary absolute take. Panic is rarely used for error handling and nobody is advocating for its use in practice. I wouldn't use os.Exit() in deeper layers of code myself, it's better to have OS level startup / shutdown in a single / central location so that the other layers of a nontrivial application don't need to be aware of it. Having a recover block somewhere allows for graceful shutdown and logging, whereas using os.Exit() in random places would require you to write a utility function or repeat the shutdown / logging procedure.

by bb88 2y ago

jitl 2y ago

panic/recover is good and necessary to have, Rust also has this. Swift’s fatalError is not recoverable which is very frustrating. I don’t like go much - languages that can have nil pointer errors can take a hike, but what I like even less than a nil pointer error while handling a request, is for my whole process to die unrecoverably because someone forgot to check a nil in an infrequently called API. Or when comparing something that’s not allowed to be compared. Like the language would be better if these mistakes were impossible to make, but as long as we have a language with a plethora of garden variety syntax can panic like `a.b` or `a == b` we should be able to mitigate that risk at runtime.

bb88 2y ago
In golang, `panic()` and `return err` are two different ways of unwinding the stack. 80% of my error handling in go is `return nil, err`. But there's no reason syntactic sugar couldn't be applied for something like `when err { return nil, err} { err := doSomething() }`

Cthulhu_ 2y ago

I think this is an unneccesary absolute take. Panic is rarely used for error handling and nobody is advocating for its use in practice. I wouldn't use os.Exit() in deeper layers of code myself, it's better to have OS level startup / shutdown in a single / central location so that the other layers of a nontrivial application don't need to be aware of it. Having a recover block somewhere allows for graceful shutdown and logging, whereas using os.Exit() in random places would require you to write a utility function or repeat the shutdown / logging procedure.