3 ms·

Go's error handling really reminds me of errbacks in node (callback function with a possible error as first argument), with many of the same pitfalls. I wonder

Go's error handling really reminds me of errbacks in node (callback function with a possible error as first argument), with many of the same pitfalls. I wonder why so many people defend Go's choices here in comparison?

kungtotte 6y ago
Go is aiming to be a slightly better C. If you look at it from a C programmer's perspective then Go streamlines the typical C control flow of error values by letting you return a value and an error code. It's not trying to revolutionise the world.
BenoitEssiambre 6y ago
"errbacks" definitely have benefits since having the error parameter forces you to think "where should I handle this error". With exceptions, people often get sloppy and let them be thrown and handled wherever, often at the wrong place. Now it does make code more verbose since 90% of the time, the answer to "where should I handle this error" is "not right here" and with go/errbacks, you have to be explicit in that case while it is the default for exceptions. For Javascript, I recently wrote a module that allows you to jump between styles very easily: https://github.com/bessiambre/casync#readme https://github.com/bessiambre/casync#readme
- phpnode 6y ago
  The benchmarks in that library are misleading - by wrapping the resolve in the promise example in a process.nextTick you're actually making the engine enqueue 2 microtasks, as promises are always guaranteed to be async. If you remove the process.nextTick the results are reversed, I get: - 63ms (async) - 100ms (casync) so it's almost twice as slow as native async await in this example.
  - BenoitEssiambre 6y ago
    The main reason for this library has to do with simplification more than performance but just for the sake of argument, in my little benchmark, the point was to make the asynchronous operation identical in both tests. You can use promises without any asynchronous operation inside but what's the point? That's not how they're used most of the time. And sure promises may add a second microtask around the asynchronous code (casync does too in some cases) but that is to their detriment performance wise (and do promises really add a second microtask when the code inside is already asynchronous?). Also note that async has the benefit of language level integration and optimization. It gets to use v8 c++ functions like "EnqueueMicrotask" instead of process.nextTick. If casync had access to all this, it would likely run even faster.
greyman 6y ago
I agree with the article. First I had to get used to it, and now I like it. 1) It forces a programmer to think about all possible errors right when calling a method, and handle them, and 2) reading other people code is easier - I see right away which errors can happen exactly and how they were handled. I code in Go about 50% of my time, while the other 50% is Python. There, the code looks more elegant at the first sight, and yes, is not so-called "polluted" with error handling, but it takes more time to understand what it precisely does in all possible cases. Overall, I really started to prefer the Go, more explicit, way.

kungtotte 6y ago

Go is aiming to be a slightly better C. If you look at it from a C programmer's perspective then Go streamlines the typical C control flow of error values by letting you return a value and an error code. It's not trying to revolutionise the world.

BenoitEssiambre 6y ago

"errbacks" definitely have benefits since having the error parameter forces you to think "where should I handle this error". With exceptions, people often get sloppy and let them be thrown and handled wherever, often at the wrong place. Now it does make code more verbose since 90% of the time, the answer to "where should I handle this error" is "not right here" and with go/errbacks, you have to be explicit in that case while it is the default for exceptions. For Javascript, I recently wrote a module that allows you to jump between styles very easily: https://github.com/bessiambre/casync#readme https://github.com/bessiambre/casync#readme

phpnode 6y ago
The benchmarks in that library are misleading - by wrapping the resolve in the promise example in a process.nextTick you're actually making the engine enqueue 2 microtasks, as promises are always guaranteed to be async. If you remove the process.nextTick the results are reversed, I get: - 63ms (async) - 100ms (casync) so it's almost twice as slow as native async await in this example.
- BenoitEssiambre 6y ago
  The main reason for this library has to do with simplification more than performance but just for the sake of argument, in my little benchmark, the point was to make the asynchronous operation identical in both tests. You can use promises without any asynchronous operation inside but what's the point? That's not how they're used most of the time. And sure promises may add a second microtask around the asynchronous code (casync does too in some cases) but that is to their detriment performance wise (and do promises really add a second microtask when the code inside is already asynchronous?). Also note that async has the benefit of language level integration and optimization. It gets to use v8 c++ functions like "EnqueueMicrotask" instead of process.nextTick. If casync had access to all this, it would likely run even faster.

greyman 6y ago

I agree with the article. First I had to get used to it, and now I like it. 1) It forces a programmer to think about all possible errors right when calling a method, and handle them, and 2) reading other people code is easier - I see right away which errors can happen exactly and how they were handled. I code in Go about 50% of my time, while the other 50% is Python. There, the code looks more elegant at the first sight, and yes, is not so-called "polluted" with error handling, but it takes more time to understand what it precisely does in all possible cases. Overall, I really started to prefer the Go, more explicit, way.