Designing for Scalability with Erlang/OTP

Chapter 8. Supervisors

Now that we are able to monitor and handle predictable errors, such as running out of frequencies, we need to tackle unexpected errors arising as the result of corrupt data or bugs in the code. The catch is that unlike the errors returned to the client by the frequency allocator or alarms raised by the event managers, we will not know what the unexpected errors are until they have occurred. We could speculate, guess, and try to add code that handles the unexpected and hope for the best. Using automated test generation tools based on property-based testing, such as QuickCheck or PropEr, can definitely help create failure scenarios you would never devise on your own. But unless you have supernatural powers, you will never be able to predict every possible unexpected error that might occur, let alone handle it before knowing what it is.

Too often, developers try to cater for bugs or corrupt data by implementing their own error-handling and recovery strategies in their code, with the result that they increase the complexity of the code along with the cost of maintaining it (and, yet handle only a fraction of the issues that can arise, and more often than not, end up inserting more bugs in the system than they solve). After all, how can you handle a bug if you don’t know what the bug is? Have you ever come across a C programmer who checks the return values of printf statements, but is unsure of what to do if an error actually occurs? If you’ve come to Erlang from ...