2 ms·
Not noticing it is exactly my fear. Passing an error manually up several levels when it may only be a theoretical concern is a ton of expressive duplication. I
by wpietri 5y ago
Not noticing it is exactly my fear.
Passing an error manually up several levels when it may only be a theoretical concern is a ton of expressive duplication. If I'm in the mindset, that would feel like valuable work, even though it isn't actually making things better for users.
It reminds me of one team I dealt with years ago. They were Java experts used to doing enterprise stuff; their overlords had put them on a scrappy, startup-like thing that was intended to be open source. As was in fashion for Java at the time, they had written things in many layers, the goal of which was to provide scaling cut-points. However valuable in theory, the project ever needing to scale was uncertain. What really mattered was finding something that served user needs. But the layer-by-layer duplication increased the cost of change significantly, lowering the odds we'd find the right product.
- preseinger 5y agoWhat you call "expressive duplication" I call "explicit intent". The error control flow is not subordinate to the happy path.
- wpietri 5y agoI'm not following. I can be explicit without being duplicative. The more I repeat an expression of a single concept, the harder I make refactoring when I discover the concept needs to change. That's why, e.g., copy-paste programming is such a bad idea for most projects.
- preseinger 5y agoI'm not sure how this would apply. You'll never refactor away the error handling idioms of the language itself.
- wpietri 5y agoExactly. If the error-handling idioms of the language force me to be duplicative in ways that make useful work harder, then it sounds like it's not the right language for the project in question.