There is one area where the designers of Java chose not to detect errors automatically: *numerical computations*. In Java, a value of type *int* is represented as a 32-bit binary number. With 32 bits, it’s possible to represent a little over four billion different values. The values of type int range from -2147483648 to 2147483647. What happens when the result of a computation lies outside this range? For example, what is 2147483647 + 1? And what is 2000000000 * 2? The mathematically correct result in each case cannot be represented as a value of type *int*. These are examples of **integer overflow**. In most cases, integer overflow should be considered an error. However, Java does not automatically detect such errors. For example, it will compute the value of 2147483647 + 1 to be the negative number, -2147483648. (What happens is that any extra bits beyond the 32-nd bit in the correct answer are discarded. Values greater than 2147483647 will “wrap around” to negative values. Mathematically speaking, the result is always “correct modulo 2^{32}.”)

For example, consider the following program. Starting from a positive integer N, the program computes a certain sequence of integers:

while ( N != 1 ) { if ( N % 2 == 0 ) // If N is even... N = N / 2; else N = 3 * N + 1; System.out.println(N); }

But there is a problem here: If N is too large, then the value of 3*N+1 will not be mathematically correct because of integer overflow. The problem arises whenever 3*N+1 > 2147483647, that is when N > 2147483646/3. For a completely correct program, we should check for this possibility **before** computing 3*N+1:

while ( N != 1 ) { if ( N % 2 == 0 ) // If N is even... N = N / 2; else { if (N > 2147483646/3) { System.out.println("Sorry, but the value of N has become"); System.out.println("too large for your computer!"); break; } N = 3 * N + 1; } System.out.println(N); }

The problem here is not that the original algorithm for computing 3N+1 sequences was wrong. The problem is that it just can’t be correctly implemented using 32-bit integers. Many programs ignore this type of problem. But integer overflow errors have been responsible for their share of serious computer failures, and a completely robust program should take the possibility of integer overflow into account. (The infamous “Y2K” bug was, in fact, just this sort of error.)

For numbers of type double, there are even more problems. There are still overflow errors, which occur when the result of a computation is outside the range of values that can be represented as a value of type double. This range extends up to about 1.7 times 10 to the power 308. Numbers beyond this range do not “wrap around” to negative values. Instead, they are represented by special values that have no real numerical equivalent. The special values

*Double.POSITIVE_INFINITY *and *Double.NEGATIVE_INFINITY*

represent numbers outside the range of legal values.

For example, 20 * 1e308 is computed to be *Double.POSITIVE_INFINITY*.

Another special value of type *double*, *Double.NaN*, represents an illegal or undefined result. (“NaN” stands for “Not a Number”.) For example, the result of dividing zero by zero or taking the square root of a negative number is Double.NaN. You can test whether a number x is this special not-a-number value by calling the boolean-valued function *Double.isNaN(x)*.

For **real numbers**, there is the added complication that most real numbers can only be represented approximately on a computer. A real number can have an infinite number of digits after the decimal point. A value of type double is only accurate to about 15 digits. The real number 1/3, for example, is the repeating decimal 0.333333333333…, and there is no way to represent it exactly using a finite number of digits. Computations with real numbers generally involve a loss of accuracy. In fact, if care is not exercised, the result of a large number of such computations might be completely wrong! There is a whole field of computer science, known as numerical analysis, which is devoted to studying algorithms that manipulate real numbers.

So you see that not all possible errors are avoided or detected automatically in Java. Furthermore, even when an error is detected automatically, the system’s default response is to report the error and terminate the program. This is hardly robust behavior! So, a Java programmer still needs to learn techniques for avoiding and dealing with errors. These are the main topics of the next three sections.