Perspectives
Errors Reveal the Assumptions We Forgot We Made
An error does more than stop work. It can reveal a condition we silently assumed would always be true: the file exists, the network is reachable, the response arrives on time.
An error does more than stop work. It can reveal a condition we silently assumed would always be true: the file exists, the network is reachable, the response arrives on time. Those assumptions stay invisible on the happy path and become visible under failure.
Suppose a required configuration value is missing. The code fails where it tries to use the value, but the useful question is larger than that line: was the value truly mandatory, and where should that requirement have been validated?
Hiding an error and handling an error are different things. Replacing failure with an empty result can move the problem into a later and more ambiguous layer. Saying what is unknown and why execution stopped usually makes investigation easier.
I like to treat debugging as a doorway into assumptions. I ask not only what broke, but which expectation broke. Correcting that expectation turns one failure into a lesson about the design.