What If Something Goes Wrong?

Exceptional or Error Conditions

The last thing to analyze when developing a function is what to do if something goes wrong in the function. 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 test for attempting 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 effective 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 function 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 function 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 function from attempting to conduct the division.

The same goes for the factorial function. If your function finds that a number too large for the operation has been passed to the function 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 function input or output, but if there is something that your function does protect itself from, you should note that in the process description of the function.

As mentioned, the exceptional or error conditions are a result of the function 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 functions analyzed for preconditions, and why you may need to handle exceptions or errors.

Wrapping up function development concepts. Even though you may be asked in a class to write individual functions, when you are really developing a program, the actual development of functions is not a stand-alone process. You will be developing functions 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 functions will be addressed in the next sections after you have read about the main function.