3 ms·
The problem is that most of the time, errors are not to be handled but only bubbled up. I've also seen it in Java with checked exceptions: the more explicit err
by speed_spread 2y ago
The problem is that most of the time, errors are not to be handled but only bubbled up. I've also seen it in Java with checked exceptions: the more explicit error handling is, the more developers feel they should somehow try to do _something_ with the error when the correct thing to do would actually be to fail in the most straightforward manner. The resulting code is often much heavier than necessary because of this and the stacktraces also get polluted by overwrapping.
- mikeschinkel 2y agoSounds like a lack of good code review.
- speed_spread 2y agoThat's just another way of dismissing the problem as a "skill issue" and is not helpful. While the problem can be prevented by having strong coding standards, many teams do not have the luxury of wisdom and thus recreate this exception tar pit again and again.
- Mawr 2y agoThe problem with the opposite is, since everything gets invisibly bubbled up to the top, you are not able to tell what errors do need to be handled. You only find those out from runtime failures and that's no good if you care about reliability.
- speed_spread 2y agoYou are right, I wouldn't want totally invisible bubbling either. I like Rust's ? notation although it's not perfect and I'm sure another language could do better maybe with more structured error classes.