3 ms·

Yes. The point is the extra steps mean that the delta between “just bubbling up” and “doing something about it” is smaller, which increases the chance that you'

Yes. The point is the extra steps mean that the delta between “just bubbling up” and “doing something about it” is smaller, which increases the chance that you'll consider “doing something about it.” If “bubbling up” is infinitely easier than handling it, you'll postpone handling it as much as you can.

chuckadams 3y ago
Yet most Go code in the wild does nothing but bubble up the error. Three out of every four lines of code dedicated to doing nothing more than that. If only there were syntax sugar doing so automatically, maybe even a compiler mechanism for forcing you to declare those that you do push up to the caller in such fashion... I don't even particularly like exceptions either, I just like having to implement them by hand even less. Meanwhile, all the Smug Lisp Weenies™ are chuckling and mumbling something about "restarts". What really kills me is that Go has a structured exception mechanism with panic/recover/defer, and it's actually better than try/catch/finally at that. It just doesn't seem to have caught on as the standard exception handling idiom.
- groestl 3y ago
  > It just doesn't seem to have caught on as the standard exception handling idiom. Not only that, but there is heaps of code which is correct in the presence of errors (after all, Go developers tend to obsess a lot about them), but leaks resources in the presence of panics. Those just fly under the radar of most Go programmers. Good thing Go introduced defer. Because the panic-safe era (similar to the exception-safe era of C++) seems to be an era yet to come for the Go ecosystem.
groestl 3y ago
> you'll postpone handling it as much as you can. Which is exactly what you should do if you are in the game to build reliable complex systems. See my lengthy post here https://news.ycombinator.com/item?id=39808367 https://news.ycombinator.com/item?id=39808367
- ncruces 3y ago
  Your lengthy post just argues you shouldn't “mask” errors in random places. Well that's great that no one said you should. Error handling is not masking, or swallowing errors.

chuckadams 3y ago

Yet most Go code in the wild does nothing but bubble up the error. Three out of every four lines of code dedicated to doing nothing more than that. If only there were syntax sugar doing so automatically, maybe even a compiler mechanism for forcing you to declare those that you do push up to the caller in such fashion... I don't even particularly like exceptions either, I just like having to implement them by hand even less. Meanwhile, all the Smug Lisp Weenies™ are chuckling and mumbling something about "restarts". What really kills me is that Go has a structured exception mechanism with panic/recover/defer, and it's actually better than try/catch/finally at that. It just doesn't seem to have caught on as the standard exception handling idiom.

groestl 3y ago
> It just doesn't seem to have caught on as the standard exception handling idiom. Not only that, but there is heaps of code which is correct in the presence of errors (after all, Go developers tend to obsess a lot about them), but leaks resources in the presence of panics. Those just fly under the radar of most Go programmers. Good thing Go introduced defer. Because the panic-safe era (similar to the exception-safe era of C++) seems to be an era yet to come for the Go ecosystem.

groestl 3y ago

> you'll postpone handling it as much as you can. Which is exactly what you should do if you are in the game to build reliable complex systems. See my lengthy post here https://news.ycombinator.com/item?id=39808367 https://news.ycombinator.com/item?id=39808367

ncruces 3y ago
Your lengthy post just argues you shouldn't “mask” errors in random places. Well that's great that no one said you should. Error handling is not masking, or swallowing errors.