Continuing on the topic of error handling, I thought I would change the direction today, and talk more about error and exception handling as a philosophy, instead of focusing on syntax, etc. There are many purposes for error handling. Two stand out to me as very significant.
If something bad happens, disrupting the user’s experience, error handling should tell me, as the user, what I need to do to solve the problem. A printer is a great example of error handling. When it is out of paper, printers often return a message telling the user that their document is not being printed, because no paper is available, when they try to print.
Developers have a different need for information when things go wrong. They want details. What was being executed when an exception occurred? What was the state of the system? What was the specific exception message? Was there more than one exception? These details are essential for developers, but, in most systems, are not appropriate to pass on to end users. It could reveal too much information regarding how you system is designed, providing insight to hackers. It may also provide sensitive data you need to protect.
With the escalation of distributed systems, error and exception handling techniques increase in importance. You can’t always pass to the user enough information to detect and handle bugs. Too, you can’t always run service software in a debug window in order to trap the offending error. This exposes the fact that, in modern distributed software, error/exception handling is essential, to build systems that can be debugged and maintained. If you build your systems with error logging in place, as you handle the errors, you have the ability to track and view issues as they arise.
There are many logging libraries for the different programming languages. The mature ones have an extensible architecture, allowing you use a central logging capability, and have the log events routed to one or more listeners, defined as logging extensions specific to a certain logging destination. Listeners are usually available for files, database, messaging, email, and much more.
One of my favorite listeners is an UDP listener, allowing you to broadcast over UDP. There are UDP apps that capture UPD traffic and display it on a screen or window. Because UDP is a broadcast protocol, the message is available to anyone who knows one what address to listen. Of course the network guys don’t like the noise. Another thing that makes the UDP listener attractive is when you have multiple machines working together as a single service. Listening to an UDP logger allows you to get the messages from all servers in a single window. If you want to persist the UDP messages, redirect your UDP listener output to a file. You can then use a Tail program to view new messages as the arrive in the file.
In conclusion, with distributed systems, exception handling and logging is essential to debug and maintain your software
.
Cheers,
Ben