3 ms·

Watching go people complaining about how other languages encourage bubbling errors up is always hilarious to me because there is literally nothing you can do wi

Watching go people complaining about how other languages encourage bubbling errors up is always hilarious to me because there is literally nothing you can do with errors in go except bubble them up, log them, or swallow them. Even the article considers "handling" an error to be synonymous with "Adding more text and bubbling it up"!

gwd 1y ago
I mean, yeah, most of the time what you do is add more text and bubble up. But: 1. The very fact that adding more text isn't really any more verbose than not encourages you to add more text, making errors more informative. 2. A non-negligible amount of times you do something else: carry on, or do something specific based on what kind of error it was. For instance, ignore an error if it's in a certain class; or create the file if it didn't exist; and so on. Forcing the error handling doesn't seem to me that different than forcing you to explicitly cast between (say) int and int64. Part of me is annoyed with that too, but then I have PTSD flashbacks from 20 years of C programming and appreciate it.
- DangitBobby 1y ago
  > making errors more informative. It makes them almost as informative as languages with stack traces! Imagine if Go had a syntax like python's raise Exception("bad thing happened") from err I'd love that.
tail_exchange 1y ago
> there is literally nothing you can do with errors in go except bubble them up, log them, or swallow them You can also add additional context to the error before bubbling it up. But yes, that part of the point. Instead of bubbling them up, the programmer should instead reflect on whether it is better than just log and proceed, or completely swallow them. This is what error handling is about.
Mawr 1y ago
I assume you mean languages with exceptions. You can't bubble up an exception, it's done automatically. That's a very important distinction. You can't make the decision to bubble up or not, because you do not have the required information - you don't know whether an exception can be thrown or not at any point. Therefore, you can't say you're making a decision at all. Explicit error allows you to be able to make the decision.
- DangitBobby 1y ago
  No. Exceptions means the default is to bubble up. You can always write special handling code to prevent bubbling it up if you want in a language with exceptions. So it's: Rely on the programmer to identify that an error was made and in 95% of situations just bubble it up, do something useful 5% of the time, but "deal with" the error 100% of the time OR Rely on the programmer to identify the 5% of situations where they don't want the error to just bubble up and add special handling for that case specifically.

gwd 1y ago

I mean, yeah, most of the time what you do is add more text and bubble up. But: 1. The very fact that adding more text isn't really any more verbose than not encourages you to add more text, making errors more informative. 2. A non-negligible amount of times you do something else: carry on, or do something specific based on what kind of error it was. For instance, ignore an error if it's in a certain class; or create the file if it didn't exist; and so on. Forcing the error handling doesn't seem to me that different than forcing you to explicitly cast between (say) int and int64. Part of me is annoyed with that too, but then I have PTSD flashbacks from 20 years of C programming and appreciate it.

DangitBobby 1y ago
> making errors more informative. It makes them almost as informative as languages with stack traces! Imagine if Go had a syntax like python's raise Exception("bad thing happened") from err I'd love that.

tail_exchange 1y ago

> there is literally nothing you can do with errors in go except bubble them up, log them, or swallow them You can also add additional context to the error before bubbling it up. But yes, that part of the point. Instead of bubbling them up, the programmer should instead reflect on whether it is better than just log and proceed, or completely swallow them. This is what error handling is about.

Mawr 1y ago

I assume you mean languages with exceptions. You can't bubble up an exception, it's done automatically. That's a very important distinction. You can't make the decision to bubble up or not, because you do not have the required information - you don't know whether an exception can be thrown or not at any point. Therefore, you can't say you're making a decision at all. Explicit error allows you to be able to make the decision.

DangitBobby 1y ago
No. Exceptions means the default is to bubble up. You can always write special handling code to prevent bubbling it up if you want in a language with exceptions. So it's: Rely on the programmer to identify that an error was made and in 95% of situations just bubble it up, do something useful 5% of the time, but "deal with" the error 100% of the time OR Rely on the programmer to identify the 5% of situations where they don't want the error to just bubble up and add special handling for that case specifically.