5 ms·
This is confusing, so I'll put it this way, Golang doesn't have exceptions the way someone coming from Javascript, Java, Python, ObjC... would understand: throw
by hot_gril 2y ago
This is confusing, so I'll put it this way, Golang doesn't have exceptions the way someone coming from Javascript, Java, Python, ObjC... would understand: thrown anywhere and automatically propagated up the call stack unless caught.
- randomdata 2y agoThere is nothing to be confused about. The syntax may be slightly different to other languages, but there is no meaningful difference in the design. If you understand exceptions and exception handlers in those other languages, you understand them in Go. There is no exactly a lot you can do with exceptions to see them differ in any big way. Why is it that Go attract so many "experts" who have clearly never used the language even just once?
- hot_gril 2y agoI understand how to use them in Golang, it's just annoying to have to keep checking and returning errors everywhere.
- randomdata 2y agoThe language doesn't impose this upon you. You can use the exception handling system to pass values around, just like you might in the aforementioned languages. Even Go's standard library does it. Read the encoding/json source sometime. You might impose it upon yourself when you start to understand the pitfalls of using exceptional handlers for anything other than exceptions, but such is engineering. Everything comes with tradeoffs.
- hot_gril 2y agoWhat's imposed on a Golang user is two choices, panic/recover or regular error handling, and almost always you take the latter. There's no option of using exceptions the same way you would in most other languages.
- randomdata 2y agoSame as all of those other languages mentioned. What gives you the impression that Go is somehow magically different? Or have I misinterpreted you?
- unbrice 2y agoOne technical challenge to using panic to represent normal exceptions is that most go code is then not exception safe. This was a design choice for the ecosystem if not the language itself (see eg: Effective go about panic not crossing package boundaries, or Google's style guide). Within a package it can work, but then you'll find language support lacking. For example defer is scoped to a function so you need to write pretty unusual code to make the equivalent of a try block.
- shepherdjerred 2y agoLike randomdata said, Go does have this with panic/recover, it's just that Go programmers (from what I have seen) greatly prefer Error types which do not automatically propagate up the stack until caught. Go _doesn't_ have any form of checked exceptions, though, which are required by the compiler to be caught by the caller.
- hot_gril 2y agoGolang programmers indeed don't prefer panic/recover, but that's not comparable to exceptions in other languages.
- tsimionescu 2y agoPanic/recover is perfectly equivalent to try/catch in most languages. There is some small difference related to exactly how un caught panics are handled (in Java, an un caught exception kills the thread that raised it; in Go, it kills the whole Go process); and the amount of built-in type checking for recover vs catch (but you can do manual typechecking and re-panic from a recover if you want). But otherwise they are almost perfectly equivalent. Of course, Go code uses panics much more sparingly than Java or C# or JS or Python use exceptions.
- hot_gril 2y agoIt's different syntax, less convenient, and less obvious what you're try-catching. Also you can't scope it to just part of the function. func outer() { defer catch() { if r := recover(); r != nil { fmt.Println("Recovered:", r) } }() // ... doSomething() // Can panic doSomethingElse() // Can also panic } vs JS: const outer = () => { try { doSomething() } catch(err) { console.log(err) } try { doSomethingElse() } catch(err) { console.error("dang it bobby", err) throw err } } But in any real Golang situation, you'll be working with libraries or teammates who return (type, error) instead of using panics. You might say this isn't inherent to the language, but it kinda is when all the built-in standard libraries like net/http work this way and the official language style guide tells you to do this. func outer() { r, err := doSomething() if err != nil { fmt.Println("Recovered:", r) } r, err := doSomethingElse() if err != nil { fmt.Println("Recovered else:", r) } }