Error Handling is Hard
Error Handling is Hard
Error Handling is Hard
I’d like to do a deep dive into some different ways of handling errors across programming languages, but this so far is the best example of Error State-specific coverage I’ve seen, here re: Rust and Haskell:
Like so many other things, error handling ultimately is a trade-off. When we’re writing our initial code, we don’t want to think about errors. We code to the happy path. How productive would you be if you had to derail every line of code with thought processes around the myriad ways your code could fail?
But then we’re debugging a production issue, and we definitely want to think about errors. We curse our lazy selves for not handling an error case that obviously could have arisen. “Why did I decide to abort the process when the TCP connection failed? I should have retried! I should have logged the address I tried to connect to!”
Then we flood our code with log messages, and are frustrated when we can’t see the important bits.
Finding the right balance is an art. And typically it’s an art that we don’t spend enough time thinking about. There are some well-established tools for this, like runtime-configurable log levels. That’s a huge step in the right direction.