3 ms·

Golang already has an exceptions-equivalent construct in the shape of panic() and recover(): https://blog.golang.org/defer-panic-and-recover https://blog.golang

by jitl 8y ago

Golang already has an exceptions-equivalent construct in the shape of panic() and recover(): https://blog.golang.org/defer-panic-and-recover https://blog.golang.org/defer-panic-and-recover You’re free to write exception-full code using those constructs, although the community tends to use error return values for the most part.

bb88 8y ago
This is how I understood the use for panics: https://stackoverflow.com/questions/44504354/should-i-use-panic-or-return-error https://stackoverflow.com/questions/44504354/should-i-use-pa... > You should assume that a panic will be immediately fatal, for > the entire program, or at the very least for the current > goroutine. Ask yourself "when this happens, should > the application immediately crash?" If yes, use a panic; > otherwise, use an error. In Java, say, exceptions are the standard for raising a normal error. A class of those exceptions are runtime errors which are equivalent of "panics". Yes you can handle them, but they denote a problem with the program that can't be solved by the interpreter (divide by zero error, etc)
- ithkuil 8y ago
  If want (and if it makes sense) you can use panics as a control flow mechanism to quickly bubble up errors inside your implementations. See an example in the standard library itself: https://golang.org/src/encoding/json/encode.go https://golang.org/src/encoding/json/encode.go, line 295 What's frowned upon is leaking this out of your package's interface/contract.
  - bb88 8y ago
    Then it strikes me kind of like C++ exceptions. They have them, and it's kinda supported, and there are certain things you shouldn't do with them, so everyone just uses return codes. Java/Python encourage the use of exceptions as returning error conditions, rather than return error codes.
IshKebab 8y ago
panic() and recover() are not meant to be used like Java or C++ exceptions.
- vorg 8y ago
  The phrase "are able to be" is more effectual than the phrase "are not meant to be" when it comes to how people use programming languages in the real world. If it's possible to build a Go system using only panic/recover and defer, just as it is using only interface{}, then there's some people who will use them that way.

by jitl 8y ago

bb88 8y ago

This is how I understood the use for panics: https://stackoverflow.com/questions/44504354/should-i-use-panic-or-return-error https://stackoverflow.com/questions/44504354/should-i-use-pa... > You should assume that a panic will be immediately fatal, for > the entire program, or at the very least for the current > goroutine. Ask yourself "when this happens, should > the application immediately crash?" If yes, use a panic; > otherwise, use an error. In Java, say, exceptions are the standard for raising a normal error. A class of those exceptions are runtime errors which are equivalent of "panics". Yes you can handle them, but they denote a problem with the program that can't be solved by the interpreter (divide by zero error, etc)

ithkuil 8y ago
If want (and if it makes sense) you can use panics as a control flow mechanism to quickly bubble up errors inside your implementations. See an example in the standard library itself: https://golang.org/src/encoding/json/encode.go https://golang.org/src/encoding/json/encode.go, line 295 What's frowned upon is leaking this out of your package's interface/contract.
- bb88 8y ago
  Then it strikes me kind of like C++ exceptions. They have them, and it's kinda supported, and there are certain things you shouldn't do with them, so everyone just uses return codes. Java/Python encourage the use of exceptions as returning error conditions, rather than return error codes.

IshKebab 8y ago

panic() and recover() are not meant to be used like Java or C++ exceptions.

vorg 8y ago
The phrase "are able to be" is more effectual than the phrase "are not meant to be" when it comes to how people use programming languages in the real world. If it's possible to build a Go system using only panic/recover and defer, just as it is using only interface{}, then there's some people who will use them that way.