How to code for Alternate Course AKA Rainy Day Scenary?

Question

Alternate course is something when user doesn't do what you expected, e.g. key in wrong password, pressing back button, or database error.

For any programming project, alternate course accounts for more than 50% of a project timeline. It is important. However, most computer books only focus on Basic Course (when everything goes fine).

Basic course is rather simple, compared to Alternate course, because this is normally given by client. Alternate course is what we, as a programmer or Business Analyst needs to take care of.

Java has some built-in mechanism (try-catch) to force us to handle those unexpected behavior. The question is, how to handle them? Any pattern to follow?

Any guideline or industry practice for handling alternate course?

Answer 1

Exception handling isn't an appropriate method to deal with "alternate course" behaviour in the operation of a system. Typically there are performance penalties associated with utilizing exceptions during the normal course of an operation, and in addition exceptions usually contain information and are targeted more towards dealing with cases unanticipated by the developer or otherwise unaddressable by the program (at least at that point in execution, upstream callers may have a way to address the exception).

Typically when designing a piece of software, I subscribe fairly heavily to developing personas and outlining use cases based on the client's requirements. Use cases, when done properly, should always include "alternate courses" (or secondary use cases) that describe scenarios outside of typical program flow. Treating secondary use cases as first class citizens rather than an afterthought ensures that secondary behaviour is designed, developed and tested with the same degree of attention as the primary flow through the application.

Answer 2

Alternate courses are vastly reduced by validating user input, as well as results from components. (These would eliminate two of your examples.).

My suggestion would be to ensure that each course of action is documented, with the allowed inputs detailed.

Any action which falls outside this, will typically be a bug, however these can be logged, and if necessary alternative courses can be built into your software.

An issue like someone clicking the back button will typically not be picked up by this approach, so I recommend lots of peer reviews, prototyping and iterative development.

I prefer the approach of tightening up your basic courses, any action which is permitted is no longer an alternate course and should be dealt with accordingly. (As Ryan says.).