Errors should never pass silently
One my favorite wisdom on coding is the Zen of Python. There is so much experience summarized in them.
Today I want to tackle: Errors should never pass silently.
Let’s say you are coding a logic that expects one element in an array. Now, let’s say you found an empty array. What do you do? Do you throw an exception or do you return null since there is nothing in the array?
Similarly, let’s say you are reading from a file and you got an error while accessing the file. What do you do? Do you fail at this time or do you return an empty String instead?
If you decided not to throw an exception, you most probably did it to avoid an outage or something around this line. The thing though is that the outage has already happened. You just passed the buck to someone/somewhere else.
If you had thrown, what would have been a short time to find the root cause in an outage becomes multiple hours as the exception is masqueraded now into null exception, weirdness in the system, etc…
It is always better to throw/fail or try to recover rather than fail silently.
I think this is so important that Golang decided to get rid of exceptions and have the following pattern.
resp, err := methodThatThrow()
The reason this is great is that it pushes you right now and there to decide on what to do with the err.
Mastering Software Engineering Course on Maven
If you liked this article, I will be teaching a “Mastering Software Engineering” course on Maven where I will teach hard-learned lessons I acquired developing large-scale products at companies such as Uber, Airbnb, and Microsoft.
Thanks for reading Software Engineering Tidbits! Subscribe for free to receive new posts and support my work.