Studying the relationship between exception handling and post-release defects
At my first job I wrote a new Java application to ingest&#x2F;transform&#x2F;store some data and after about 6 months it was done. It chugged along for years after without ever really requiring any maintenance or monitoring, it just kept working. One day the VP eng just showed up at my desk and started chatting, I didn&#x27;t really know why. Turns out he was interested in knowing why it was so stable but it was an obvious part of software to me - every line I wrote where an exception was possible, I would look up what exceptions could be thrown and why, and then structure try catches to do the right thing in each case - sometimes that meant logging a warning, sometimes propagating to a higher level, sometimes shutting down the app etc. He then sent out some paper about the relationship between good error handling and software defects to the org.<p>Like I don&#x27;t get why this is so difficult for so many devs. Your job is to think about both the happy case and the error cases, and usually there are many error cases and 1 happy case so the bulk of time and code is dedicated to the errors. Since then I&#x27;ve seen this is not at all the way most devs write things. They are interested in writing the happy case and treat error handling like a chore to be done as quickly as possible. The tools and language constructs don&#x27;t matter much, it&#x27;s just do you dedicate time and care to thinking through errors or not.<p>Yeah it sounds boastful but fuck it it&#x27;s true. Same is true regardless of this study it&#x27;s not about the structure and syntax of error handling,it&#x27;s how much thought was given to understanding the failure modes and how to handle them.