The term "happy case" refers to making the assumption that everything proceeds correctly and as expected when working through a use case. Happy case is important as it defines the desired behaviour for the use case. In production things will not always proceed correctly. Being aware of this and developing your application to deal with it is one of the differentiators between amateur and professional software developers.

I've previously discussed that sometimes your application just needs to die. This applies to errors that are unrecoverable. It should not apply to minor errors or unusual but valid conditions. Your application crashing (in a controlled fashion) because its database is unavailable is acceptable. Your application crashing because a user entered a non-numeric input where a number was expected is not. Recoverable error conditions should be detected and handled by your application.

Error conditions are only part of what your application must deal with. Applications must also deal with cases outside the usual or expected circumstances. The correct behaviour in these edge cases often varies widely from the standard happy case behaviour. It is not unusual that the majority of development effort for a feature will go into the edge cases of the feature than the standard behaviour. This often seems counter-intuitive to people on the business side. After all they rarely if ever have to deal with these cases. What these people fail to understand is that the effort required to implement a behaviour is independent of the likely usage frequency of that behaviour. Such behaviour must still be properly scoped and specified. This may be more difficult than standard cases as rarely used scenarios may be less understood or may not be treated in a clear and consistent manner. The behaviour must also be implemented and may be more complex than the standard behaviour and may require structural changes to the application in order to be supported.

The justification for handling erroneous cases is relatively obvious. Applications that do not handle these cases lack robustness and reliability and users will rightly treat these limitations as defects in the application. The justification for handling edge cases is sometime harder to define. Depending on the nature of the application, the intended audience and the available development budget there are edge cases that it may not be cost effective for the application to handle. Most of the benefit of the application will come from a core set of scenarios. The additional value gained from handling additional scenarios may not justify the additional development cost. This is ultimately a question for the business, although there may be additional constraints such as legal requirements that define the required behaviour.

It is important to consider the scenarios where edge cases exist that are not explicitly addressed to ensure that the application does not behave incorrectly. This does not imply that the application handles these cases but rather that some other mechanism, such as allowing manual procedures to be utilised, exists to support them. The alternative is that standard but inappropriate behaviour be applied to an edge case condition. This may be impossible, erroneous or require users to work around the application. In these cases the application becomes a hindrance to the business rather than providing value and as such it may be best that it have no involvement in the cases it cannot handle.