4Exceptions

Four Categories of Use Case Exceptions

All discussions of use cases acknowledge two partitions of use case structure when writing the use case descriptions: a basic flow, and deviation flows. In RUP these are called the basic flow, and alternate flows, respectively. Cockburn calls these the main success scenario (MSS), and extensions, respectively.

The basic flow/MSS is the ultimate justification for the use case. It is this flow that delivers the value desired by the user of the use case. By definition, this “happy path” (as it is affectionately known) is a no-exception condition that always achieves the goal of the use case. In a use case titled Reserve a Vehicle, the goal is for the user to obtain a vehicle reservation. In the ATM use case titled Withdraw Funds, the goal is for the ATM customer to get some money.

If the world were perfect, we would never have to write more than the happy path. But things do go wrong, and in our use cases we must describe the behavior of our system when it encounters an obstacle to its attaining the goal of the use case. This obstacle could be as simple as an invalid character in a numeric field, a more complex condition such as a needed resource being unavailable, or a system condition that forces an abnormal, premature end to the use case.

These obstacles differ in this significant way: some are recoverable, some are not. For example, an invalid input to an edit field is certainly recoverable. We inform the user of the problem, and give the user the opportunity to correct the content of the field. When we validate the input after it has been corrected, the use case continues toward its goal as if the obstacle had never occurred. The obstacle was a recoverable exception.

If the use case indicates that a needed resource is unavailable, and it is the case that the resource cannot be made available, then we cannot recover at all. This becomes an unrecoverable exception, and we must abandon our use case at this point. By definition, an unrecoverable exception never achieves the goal of the use case.

There is one other exception situation that occurs. This is the fatal exception. When we encounter a fatal exception there is no hope of recovery. Your application, or your entire system is going down. I have not found it sensible to write use cases for fatal exceptions. The possible behavior available to the application or system is invariably very limited, and the time for reacting to the fatal condition is even more limited. In a fatal exception you vector out of your application context into a higher context from which return is normally not possible.

So, we have the following conditions to consider in our use cases:

Type of Exception	Achieve or Abandon Use Case Goal?
1. No exceptions (i.e., the happy path)	Always achieved
2. Recoverable exceptions	Achieved after retry and recovery
3. Unrecoverable exceptions	Not achieved because retry fails
4. Fatal exceptions	Never achieved

What is very interesting about this matrix is this: if your use cases just considered the first two types of exceptions (happy path, and recoverable exceptions) I suggest you would have roughly 80%-90% coverage in your application’s functionality for its end-users.

When you write a use case you identify each exception (i.e., extension condition, or alternative flow) that you think of for that use case. But when you implement your use cases in an iterative process, you can gain some nice efficiencies by placing each identified exception into one of the four categories above. Then you can focus first on the happy path and recoverable exceptions, and defer the unrecoverable (and fatal) exceptions. By doing this simple categorization, you will be putting your development energies into those areas that will give you your biggest return on investment.