Handling of complementary errors in embedded software
Generally, the approach depends on if your program has a safe mode where certain outputs are always disabled, or if it must almost continue running though with reduced functionality. The former is by far the most common and the latter is typically just appearing in automotive &amp; med-tech etc mission-critical control systems.
In the former case with a safe mode, you could weigh different kinds of errors to decide if they are severe enough to merit a transition to safe mode.
And then it also depends on the nature of your system, is it RTOS/multi-process or a single-process bare metal one. In either case you might want to implement a centralized error handler, how to do so might vary. C code example of a bare metal single thread system running a simple scheduler or state machine might look like this:
// main.c
for(;;)
{
  pet_wdog();
  result = run_state_machine[state]();
  if(result != OK)
  {
    error_handler(result, &amp;state);
  }
}

Your error handler can then check the type of error returned from each state (or task, module etc), then make a decision based on the error. What state should it switch to next etc. Optionally you could run some callbacks from the error handler if that makes sense, in order to keep the module-specific code (disabling outputs etc) in the module where it belongs.
The advantage of handling all errors and state transitions from a single place is to avoid &quot;stateghetti&quot;, a form of spaghetti programming where a state machine etc changes states from all over the place, with numerous local error handlers. Such designs make trouble-shooting and maintenance a real pain.
As for how you want to draw this design, that's not really important. Use UML, old school state charts or just some manner of generic bubbles &amp; arrows. Long as the code reflects what you have drawn. What's most important is to give the design some thought before you start coding away. Re-designing an existing program is always a major task with high probability of introducing errors. Better then to get the design right from scratch... which is of course easier said than done.