3 ms·
> If a segment has 6 function calls and you want the same error handling for each one, you can't get rid of the boilerplate with the current language. My deepe
by 9rx 2y ago
> If a segment has 6 function calls and you want the same error handling for each one, you can't get rid of the boilerplate with the current language.
My deepest sympathies for the person who has to respond to the resultant error once you've collected your paycheque and have moved on to the next project. Which of the six functions produced the error? Nobody knows. That may be all well and good for a contrived internet comment example, but if you write real code like that someone's life is soon going to become a living hell.
Every other language has recognized that you can't have the same error handling for each of the function calls. Even where they have special error handling semantics have special ways to ensure that the handling is different in each case. Why do you think it would work in Go?
> Assume the original error is not my own then.
Then you've forever hitched your horse to their code. A better or more performant replacement comes along in the future and you want to use it instead? Too bad. You can't without breaking your own API – and for what reason?
But, okay, we accept that you like to live life on the edge (or come from the Javascript world and thus don't know any better) and if the people using your functions start having breakage, too bad so sad. However, if you're just passing values through from another package, why are you really offering your callers in the first place? Why don't they just use the other package directly?
- Dylan16807 2y agoI like how the first half of your reply assumes the difference between errors disappears, and the second half of your reply assumes the difference doesn't disappear. Just because I share handling doesn't mean I would throw out all the information, and if I have a filesystem error while setting up a file I'm going to do the same cancellation paths no matter what particular filesystem error it is. > Then you've forever hitched your horse to their code. A better or more performant replacement comes along in the future and you want to use it instead? Too bad. You can't without breaking your own API – and for what reason? No, I did not say that. What I said is that the place to prevent that is not every function call. If my code goes 4 functions deep, I need at least one of them to handle errors I didn't cause, or convert them into my own errors for the sake of a stable API. But many of the other functions can pass errors through.
- 9rx 2y ago> But many of the other functions can pass errors through. If it only calls one function and isn't part of the public API it is likely that you can get away with it. There is a time and place for that, but if that time and place is most of the time like your earlier comment indicated and something that can be counted as many in this comment... I'd like to see this codebase because I am highly skeptical that it is something anyone would ever want to work on[1]. If it calls two or more functions, then you're back to the "which function was it?" problem. [1] And, as it happens, Google actually commissioned a study on how frequently that kind of code is actually written based on open source projects and other code they had access to when evaluating an error handling proposal. They found it to be an unusual case. It being "most" or "many" is definitely limited to within your works, not something applicable in general. There just might be a reason why your ways haven't caught on, but thrill me!