In Defense of Exceptions
I used to be a strong proponent of explicit error handling. Quite recently, I realized that exceptions are good actually.
A developer under a tight deadline does not have a strong incentive to handle all edge cases. They’ll write tests someday, right?
Many try-catch blocks I’ve seen either log the error and rethrow, which isn’t bad; or swallow it and return null 🤮 which makes the program worse, and harder to debug.
The company wants to see the happy path ASAP, you’re pressured to ship, and that’s understandable. There’s so many things that can go wrong, and time is money! You probably wouldn’t handle all of them even if you tried.
In this world, the non-ideal world of commercial software development, handling errors on another layer, like React Error Boundaries, or Darklang’s / Scott Wlaschin’s Error Rail, seems to be more practical.
Exceptions are errors we did not expect yet, but we can’t expect everything, right? Any system multiple people work on at the same time will inevitably crash at some point. Let’s learn from Erlang, and improve our fault tolerance. When we’re aware we’ll eventually crash, we ensure that:
- the user can recover, the error doesn’t propagate and bring the whole thing down,
- the call stack and application state are logged to our error tracker, so we can debug later.
Have you ever had Facebook load without the Messenger chat?
The chat is just hanging there. Yeah, it sucks it broke, but you can still read the latest conspiracy theories and see your friends’ kids pictures. In many cases it does not make sense to handle an error with more effort than unmounting the component or displaying “Something went wrong”.
If my cat tinder app can’t render because of a parse error on backend response, that used to be JSON of fluffy cats in your area, and is now HTML with a 502 Bad Gateway Error message, it’s not frontend’s responsibility to fix the bug. A generic “Something went wrong.” message is perfectly sufficient.
It’s probably the DNS anyway.