Programming by Contract:

Exceptional or Error Conditions

The last thing to analyze when developing a method is what to do if something goes wrong in the method. It is considered good practice to announce any problems found to your user and then shut down the program, if this is a necessary requirement for the circumstances. However, it is considered really bad practice if your program shuts itself down or causes other errors or issues due to problems in your program.

An exception is something a programmer might be able to predict but cannot actually control. Examples include keyboard or file input, a calculation (arithmetic) exception, etc. For an example with file access, a programmer can set up a try block for attempting the file access and then providing feedback to the user that the file was not accessed and an exception was caught. This can be managed without shutting down the program. On the other hand, if there is an out of memory error, or a stack overflow error, these are at the computer operation level and cannot be handled or managed in any way other than shutting down the program. These are called errors. The key takeaway here is that programmers should be able to contain any foreseeable issues (i.e., exceptions) by using Java's exception handling operations. You will learn more about how this actually happens later on.

Returning to the precondition examples, consider what happens if your divide method tries to divide by zero. The operating system will stop the program, report a "divide by zero" error, and shut everything down. Again, this is bad form. Your method should have caught the fact that the divisor was a zero, and then returned something indicating the problem such as zero, or at least keep the method from attempting to conduct the division.

The same goes for the factorial method. If your method finds that a number larger too large for the operation has been passed to the method as a parameter, it should return a zero and/or not let itself attempt the calculation that will almost certainly cause a register (i.e., storage location) overflow.

Unlike preconditions and postconditions, you may not need to specify the method input or output, but if there is something that your method does protect itself from, you should note that in the process description of the method.

As mentioned, the exceptional or error conditions are a result of the method being asked to do something that couldn't be done, or would cause problems for the program or computer. This is a reflection back on the preconditions and is discussed in this video that looks back on the methods analyzed for preconditions, and why you may need to handle exceptions or errors.

Wrapping up method development concepts. Even though you may be asked in a class to write individual methods, when you are really developing a program, the actual development of methods is not a stand-alone process. You will be developing methods as modular subroutines or components in your program or class, so you will be making decisions based on general program development to start with, and later based on specific needs as you flesh out the code. This complete process of developing a program along with designing your methods will be addressed in the next sections after you have read about the main method.