3 ms·
Error handling is basically orthogonal to performance. If a function call can fail, it should return an error, and that error should be managed by its caller.
by preseinger 4y ago
Error handling is basically orthogonal to performance.
If a function call can fail, it should return an error, and that error should be managed by its caller. Any other approach means callstacks are unpredictable, which makes a program way way harder to model.
- throw10920 4y ago> that error should be managed by its caller Objectively false. Correct answer: the error should be managed by the code that makes sense to handle the error. > Any other approach means callstacks are unpredictable Also false. I use conditions regularly, and my callstacks are very predictable - errors bubble upward through the call tree until they're handled. There's nothing simpler. > which makes a program way way harder to model Also false. I have no problem at all modeling and understanding my code rife with conditions.
- preseinger 4y agoYou're wrong on every point. I don't know how to speak to you given the strength of your conviction, so shrug
- throw10920 4y agoI think the fact that you didn't actually refute any of my points speaks volumes about which of us is correct.
- preseinger 4y agoWhat do you mean by "conditions"? > errors bubble upward through the call tree until they're handled. There's nothing simpler Between output_a := f1(input_a) // f1 throws exceptions on error output_b := f2(output_a) // f2 throws exceptions on error and output_a, err := f1(input_a) // inspect and deal with err output_b, err := f2(output_a) // inspect and deal with err it seems uncontroversial to me that the latter is less complicated than the former, and easier to model control flow paths. Exceptions make sense in a lot of contexts! Just not services, servers, or long-lived processes.