Error Handling

There are two competing goals for error handling. The error handling approach should be:
 * Comprehensive - explaining all errors found
 * Specific - directing you to the root cause of the problem
 * Economical - not requiring lots of processing power or memory

Error handling can be implemented using a variety of ways, but the main approaches are:
 * Exceptions - typical in Object Oriented Programming languages like Java or C++. It's very powerful, but requires more processing power.
 * Global Variable - after each operation check a particular variable to see if there is an error. This is used in C's Errno global variable. It works well, but often people forget to check it.
 * Return Value - each method returns a status, either success or an error code.

The module library uses the last approach and has a very good error handling subsystem that can be turned on or off. All functions return a value of type  which is a typedef in module_errors.h. Since many methods call other methods, these errors are "propagated" up through the stack to the main application. In addition, each method has a methodId to help in identifying the root cause of the error.

The error handling may be turned on or off by #define VERBOSE_ERROR_HANDLING. Refer to module_errors.h for more information. If the library is compiled with this option defined, then any returned errors will result in the method handleError being called. The default implementation in module_errors.c just displays the error code and method code. If you are using a debugger then you can set a hardware breakpoint in that method to trap all errors.

Note that turning off VERBOSE_ERROR_HANDLING does not disable error checking (like assertions) - it just sets whether the error is displayed.

The methods typically perform the following error handling features: There are additional errors available if you are using a fast processor. Refer to zm_phy_spi.c for more information.
 * Parameter checking - verify that the values passed into the function are valid. If not then return a INVALID_PARAMETER error.
 * Verify Called Methods - if calling another method, verify that it returns success, else propagate the error.
 * Return any modules from the module - if the module reports an error then propagate it to the calling function.