4 ms·

It'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() { d

It'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) } }

randomdata 2y ago
> Also you can't scope it to just part of the function. Why not? func outer() { func() { defer catch() { if r := recover(); r != nil { fmt.Println("Recovered from doSomething:", r) } }() doSomething() // Can panic }() func() { defer catch() { if r := recover(); r != nil { fmt.Println("Recovered from doSomethingElse:", r) } }() doSomethingElse() // Can also panic }() } I don't get why we keep getting these "expert" comments from people who have never used Go before. Hell, if you long for try/catch for some reason, you can even get creative: func try(fn func(), catch func(any)) { defer func() { if r := recover(); r != nil { catch(r) } }() fn() } func outer() { try(func() { doSomething() }, func(r any) { fmt.Println(r) }) try(func() { doSomethingElse() }, func(r any) { fmt.Println(r) }) } But then you soon start to realize how awful try/catch actually is, so...
- hot_gril 2y ago
  Try-catch is awful if you're forcing it in a language that doesn't really support it. I provided a JS try-catch example above; is there something wrong with it? The recover is still function-wide in your example, which is what I said. You can nest funcs just to deal with this, but it's ugly, and code reviewers won't like it. I use Go on my team, and yeah I'm not as expert as the team who created Go here, but idk why you keep saying I've never used it. My complaint about "if err" is pretty common among Go users, who would understand the joke of calling it "Errlang."
  - randomdata 2y ago
    > I provided a JS try-catch example above; is there something wrong with it? Yes, it suffers all the same problems. And then doesn't even help you with the errors once you get them! You then have to resort to this kind of craziness to do something with the error: try { doSomething() } catch(error) { if (error instanceof FooError) { console.log('foo') } else if (error instanceof BarError) { console.log('bar') } else if (error instanceof BazError) { console.log('baz') } else { console.log('unknown') } } Which leaves you wondering why you didn't just write: err := doSomething() switch { case errors.Is(err, ErrFoo): fmt.Println("foo") case errors.Is(err, ErrBar): fmt.Println("bar") case errors.Is(err, ErrBaz): fmt.Println("baz") default: fmt.Println("unknown") } At least Java gives you multiple catch blocks to make things slightly more sane. But I get the impression that those who find benefit in passing errors using exception handlers don't handle errors. If you don't have to worry about errors in the code you write, then I think there is a good case to be made that errors as exceptions is a better approach. That is, after all, the difference between scripts and systems. Scripts can simply fail, leaving the user to try again. Errors as exceptions, or something in the same vein, make sense as the predominant mechanism in scripting languages. Systems, on the other, have to deal with failure. You don't get to just bubble it up and let the user deal with it. This is where errors as exceptions becomes a nightmare. Go is unabashedly a systems language. It is not meant to be a scripting language. Different tools for different jobs.

randomdata 2y ago

> Also you can't scope it to just part of the function. Why not? func outer() { func() { defer catch() { if r := recover(); r != nil { fmt.Println("Recovered from doSomething:", r) } }() doSomething() // Can panic }() func() { defer catch() { if r := recover(); r != nil { fmt.Println("Recovered from doSomethingElse:", r) } }() doSomethingElse() // Can also panic }() } I don't get why we keep getting these "expert" comments from people who have never used Go before. Hell, if you long for try/catch for some reason, you can even get creative: func try(fn func(), catch func(any)) { defer func() { if r := recover(); r != nil { catch(r) } }() fn() } func outer() { try(func() { doSomething() }, func(r any) { fmt.Println(r) }) try(func() { doSomethingElse() }, func(r any) { fmt.Println(r) }) } But then you soon start to realize how awful try/catch actually is, so...

hot_gril 2y ago
Try-catch is awful if you're forcing it in a language that doesn't really support it. I provided a JS try-catch example above; is there something wrong with it? The recover is still function-wide in your example, which is what I said. You can nest funcs just to deal with this, but it's ugly, and code reviewers won't like it. I use Go on my team, and yeah I'm not as expert as the team who created Go here, but idk why you keep saying I've never used it. My complaint about "if err" is pretty common among Go users, who would understand the joke of calling it "Errlang."
- randomdata 2y ago
  > I provided a JS try-catch example above; is there something wrong with it? Yes, it suffers all the same problems. And then doesn't even help you with the errors once you get them! You then have to resort to this kind of craziness to do something with the error: try { doSomething() } catch(error) { if (error instanceof FooError) { console.log('foo') } else if (error instanceof BarError) { console.log('bar') } else if (error instanceof BazError) { console.log('baz') } else { console.log('unknown') } } Which leaves you wondering why you didn't just write: err := doSomething() switch { case errors.Is(err, ErrFoo): fmt.Println("foo") case errors.Is(err, ErrBar): fmt.Println("bar") case errors.Is(err, ErrBaz): fmt.Println("baz") default: fmt.Println("unknown") } At least Java gives you multiple catch blocks to make things slightly more sane. But I get the impression that those who find benefit in passing errors using exception handlers don't handle errors. If you don't have to worry about errors in the code you write, then I think there is a good case to be made that errors as exceptions is a better approach. That is, after all, the difference between scripts and systems. Scripts can simply fail, leaving the user to try again. Errors as exceptions, or something in the same vein, make sense as the predominant mechanism in scripting languages. Systems, on the other, have to deal with failure. You don't get to just bubble it up and let the user deal with it. This is where errors as exceptions becomes a nightmare. Go is unabashedly a systems language. It is not meant to be a scripting language. Different tools for different jobs.