Post History

In real world microcontroller systems there is very little "error handling".  There are two types of things that can go wrong, with each handled differently.

<h3>Expected conditions that prevent normal operation</h3>

These are things like a bad checksum on a command packet, the resistance between the electrodes is too low, a consumable has been depleted, etc.  Each of these should have been considered in the original design and the response thought out.

In the case of a bad checksum, you usually ignore the whole packet as if it never happened.  On some systems you might keep an error counter if there is a way to eventually get that counter to a user or a service technician.  You might also detect how often it happens and declare an error condition when it happens too often.  Again, that only makes sense if there is a means to alert the user to the problem.  You might blink a red LED, for example.  However, in many cases the only available answer is to ignore the command.  If your system is a black box, then it doesn't respond when you send it garbage.

If shorted or depleted electrodes, for example, are expected to occur in the field, then some user interface for that should be designed into the system.  Often just lighting an LED or blinking one with a specific pattern is good enough.

<h3>Actual failures</h3>

You can never "handle" all failures.  For example, if the power supply breaks, the processor might get fried or not run at all.  In the majority of cases, a broken unit acts broken.  The user either replaces it or calls field service to have it fixed or replaced.  You can't design for all contingencies.

There are an infinite number of possible failures, and detecting and handling each one adds cost.  Of course the more critical the operation of the system is, the more cost is worth spending on failure detection and handling.

For a mass-market high-volume product that most customers buy on price, like a toy for example, any extra failure detection is probably not worth it.  If it fails, the user will just toss it.

At the other end of the spectrum when safety is critical, you can spend multiple times the cost of the basic unit to reduce failures, detect them when they occur, and try to fail in the most safe possible way.  In such cases there are usually standards that the customer requires the product to be designed to.  The answer then is to do what the standard says.

<h2>Summary</h2>

Except for safety-critical systems, you detect and handle the few error conditions the system was designed for, and then just do the best you can with anything else.  Bad checksum?  Ignore the packet.  Voltage too low?  Stop operating.  Voltage too high?  You'll never know because the microcontroller is toast.