Code Leader: Using People, Tools, and Processes to Build Successful Software

12.4. Defining a Policy

So what does an exception-handling policy look like? It should be short (developers don't read documents that are longer than 1–2 pages) and to the point. It should lay out how errors are to be returned in the case of a failure, and how errors should be reported to callers. It should also define how and where errors should be documented. A complete error-handling policy for code written in C# might look something like this:

• No method shall return a code to indicate success or failure. All methods must return a result, or void if none is required. In the event of an error (meaning the method's contract cannot be fulfilled), throw an exception.

• Any exception thrown should be specific to the problem being reported and contain as complete a set of information about the problem as possible. For example, do not throw an InvalidOperationException when something more specific and descriptive is available. If a more specific exception does not exist, create one.

• All new exception types should derive from OurCompany.ActionableException or one of its descendents. Every derived class must implement a constructor that takes a source and a resolution. Every time an exception is created at runtime, a source and resolution must be provided. The source should describe to an end user what caused the problem. The resolution should describe to an end user how to resolve the problem.

• Every method that is a part of the public interface must validate its input parameters. If any ...