Bugs, logs, and fatal errors may sound like the beginning of a camping story, but in the world of software development, they might as well be the air we breathe. As such, while error handling and logging may not be the most exciting topics in programming, they are critical components that should not be ignored. It’s easy to get caught up in the enthusiasm of delivering a fully functional product, but overlooking error handling and logging can lead to issues in the development process. By incorporating these practices, developers can avoid their own campfire tales of failure and create reliable, secure, and functional software systems.
Overlooking Error Handling
If implemented, error handling and logging can help developers detect issues easily. However, I didn’t fully understand the importance of this until my first internship when I was tasked with creating a web app from scratch. When I was in college, error handling and logging were rarely taught. Instead, my focus was on passing criteria for assignments, which led to a lack of emphasis on these critical concepts. So, when I dove into building my internship project, I didn’t incorporate error handling or logging at all.
As the project progressed over the summer, I was able to implement a significant amount of the functionality. However, one day, one of my mentors posed a question that left me stumped, “What are you doing for error handling and logging?”
The idea had never crossed my mind. I initially thought the validation for text fields, which ensured the user didn’t input anything wacky, would suffice. When I shared this with my mentor, he pushed further and said, “That’s good, but what if something breaks in the code?” Again, I struggled to come up with a response. In my mind, I believed that if I wrote the code correctly and tested it thoroughly, I wouldn’t need to worry about error handling. I didn’t quite understand the purpose behind it and thought it was an unnecessary distraction from the product I was working on.
Nonetheless, my mentor convinced me that I needed to implement both error handling and logging because other people would work on this project after me, and if I used a logger, it would be easier for them to know if something was broken.
Light Bulb Moment
It was when I started working at Frogslayer that I finally wrapped my head around the significance of error handling and the need to be able to diagnose issues in production. I was assigned to work on a project that involved hardware, something I hadn’t been exposed to as a Computer Science major in college.
For the first time, I was faced with a physical object that I could manipulate using my code. Understanding the existing codebase and the underlying hardware libraries presented a challenge, but the most important thing I learned was that the different hardware components of the device were subject to their physical environment.
Anticipating all the potential scenarios a piece of hardware may experience in the real world can be difficult as there are many factors to consider, like the risk of flooding, power outages, or physical damage to the machine. When you add people to the equation, the number of possible scenarios increases exponentially. Now, while that’s true for most devices, a key consideration with this device was that staff would be interacting with it on a near-daily basis. Employees need to open the machine so they can collect any cash that has been deposited, but if they miss a step in closing the machine, it can put the device in a bad state. Moreover, even if the employees are flawless, the hardware components are still exposed to malicious actors, such as rowdy customers jamming the card dispenser or coin slot with foreign objects. These are events that are hard to predict and impossible to control as a developer.
This is when the dots connected for me: other people are going to interact with my code. People are unpredictable, and as soon as anyone other than myself interacts with the application, I no longer have control over what happens to it.
As software becomes more complex, errors can arise from various sources such as yourself, other developers (internal or external to the project), users, or hardware malfunctions. Additionally, as software relies more on external dependencies, testing every use case will become less likely and lead to bugs in production. Without proper error handling and logging, your application may lack the functionality to recover from an unexpected failure and crash. This type of situation can be stressful, as it not only affects one part of the application but can bring down an entire system. Implementing error handling and logging can mitigate the impact of errors, allowing the system to recover gracefully and ensuring a more stable software system.
Final Thoughts
While writing error handling and logging into your codebase isn’t the most exciting thing to do, the peace of mind that comes with knowing that the application is well-equipped to handle errors in production is worth it. Additionally, implementing these practices can save your client from potential revenue loss due to system downtime. If a catastrophic event occurs and something was missed, logging can be incredibly helpful in diagnosing and solving the problem quickly, reducing frustration for the users and saving money for clients. By investing time and effort into error handling and logging, developers can ensure more reliable and robust software while avoiding the stress and sleepless nights that come with system failures.
-
Koby Bailey
