3 ms·

People don't understand exceptional control flow. They think they have to catch them at every point, instead of using them as intended (having a central boundar

People don't understand exceptional control flow. They think they have to catch them at every point, instead of using them as intended (having a central boundary of error handling where you have enough context whether to retry or abort the operation). So they think Go errors are better. With exceptions you can 1. Set exception breakpoints. 2. Have real stack traces. 3. No need to write 3 lines of boiler plate every 1 line of code which interacts with outside world. Ironically this is the case in Go's niche - devopshit, cloud webshit - where the boilerplate error handling makes even less sense since because 1. You are making a network call or OS interactions every 2 lines which can err 2. The consequences of an unhandled exception are actually quite less severe. At worst your request will 500 or the application will restart - which is a consideration you can't escape in these environments. 3. I have seen indiscriminate error handling written by substandard developers which simply concatenates the full wrapped error string to API, leaking full details. At least with exceptions, you can designate different types of exception for 404s vs ayth errors vs bad requests vs Internal errors, and have a central handler which filters out. In go theoretically you can do this, but I have never seen someone utilize errors.As over stringy error handling. I like Go - it has nice stdlib, nice compiler and runtime, and actually dared to innovate away from the fat-ass LLVM monoculture and made green threads popular. But error handling and uninitialised values sticks out like a sore thumb. It's impossible to read code which does many API/network/OS interactions.

osigurdson 1mo ago
There is a reason why Rust, Go and Zig don't have exceptions and it isn't because the language designers didn't understand them. While you can achieve the same thing using both approaches, errors as return values is generally simpler to reason about. Even in C# for example, exceptions are going to start taking a back seat with tagged unions which will be much better for expected failures. I agree that Go's approach is a little cumbersome however. Suggest checking out Zig's approach which I personally think really nails it.
- win311fwg 1mo ago
  > Go [...] don't have exceptions What do you mean? Go has exceptions. Their use with errors is generally discouraged because exceptions, as the name literally implies, are technically designed for exceptional circumstances (programmer fault), not errors (environmental fault), but just like in every other language with exceptions you can do it, and even Go's own standard library uses exceptions for errors in some cases. The Go creators have even expressed openly that you should be pragmatic about it: use them for errors if it makes your code better. They are there to use.
  - osigurdson 1mo ago
    If you mean panic, it isn't really the same thing.
    - win311fwg 1mo ago
      An exception is a data structure, usually comprised of a stack trace and some kind of related data, so that's true. panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.
      - wfn 1mo ago
        I'd strongly disagree, Go panic mechanism (but not just in the runtime sense but also in language feature sense) is quite distinct from what we typically understand "exceptions" to mean (which - esp. depending on language - are not at all just about handling programmer error). I think this is a decent article on exactly this: https://medium.com/@AlexanderObregon/why-go-panics-are-different-from-exceptions-bdf43a3957c0 https://medium.com/@AlexanderObregon/why-go-panics-are-diffe... But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. Not so in Go. (Not implying some one model is better here, just flagging that panic vs exception are sufficiently distinct in meaningful (and deliberate) ways such that we can say they are "different", imho). edit p.s. s/panic/panic+defer+recover p.p.s. On exception control flow - good comment upstream by 'wannabe44, imho: https://news.ycombinator.com/item?id=49270430 https://news.ycombinator.com/item?id=49270430
throwaway2037 1mo ago
This is a very good reply -- even if it largely agrees with me. I can say another thing as a person who has spent his career writing enterprise CRUD apps: Chained exceptions are a godsend for debugging failures in enterprise CRUD apps. Sure, the exception stack trace is some kind of Cthulhu-level abomination of 100+ lines, but you have a chance to diagnose the issue given the richness of the exception stack trace.

osigurdson 1mo ago

There is a reason why Rust, Go and Zig don't have exceptions and it isn't because the language designers didn't understand them. While you can achieve the same thing using both approaches, errors as return values is generally simpler to reason about. Even in C# for example, exceptions are going to start taking a back seat with tagged unions which will be much better for expected failures. I agree that Go's approach is a little cumbersome however. Suggest checking out Zig's approach which I personally think really nails it.

win311fwg 1mo ago
> Go [...] don't have exceptions What do you mean? Go has exceptions. Their use with errors is generally discouraged because exceptions, as the name literally implies, are technically designed for exceptional circumstances (programmer fault), not errors (environmental fault), but just like in every other language with exceptions you can do it, and even Go's own standard library uses exceptions for errors in some cases. The Go creators have even expressed openly that you should be pragmatic about it: use them for errors if it makes your code better. They are there to use.
- osigurdson 1mo ago
  If you mean panic, it isn't really the same thing.
  - win311fwg 1mo ago
    An exception is a data structure, usually comprised of a stack trace and some kind of related data, so that's true. panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.
    - wfn 1mo ago
      I'd strongly disagree, Go panic mechanism (but not just in the runtime sense but also in language feature sense) is quite distinct from what we typically understand "exceptions" to mean (which - esp. depending on language - are not at all just about handling programmer error). I think this is a decent article on exactly this: https://medium.com/@AlexanderObregon/why-go-panics-are-different-from-exceptions-bdf43a3957c0 https://medium.com/@AlexanderObregon/why-go-panics-are-diffe... But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. Not so in Go. (Not implying some one model is better here, just flagging that panic vs exception are sufficiently distinct in meaningful (and deliberate) ways such that we can say they are "different", imho). edit p.s. s/panic/panic+defer+recover p.p.s. On exception control flow - good comment upstream by 'wannabe44, imho: https://news.ycombinator.com/item?id=49270430 https://news.ycombinator.com/item?id=49270430

throwaway2037 1mo ago

This is a very good reply -- even if it largely agrees with me. I can say another thing as a person who has spent his career writing enterprise CRUD apps: Chained exceptions are a godsend for debugging failures in enterprise CRUD apps. Sure, the exception stack trace is some kind of Cthulhu-level abomination of 100+ lines, but you have a chance to diagnose the issue given the richness of the exception stack trace.