|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Exceptions have several benefits. First, they allow you to separate error handling code from normal code. You can surround the code that you expect to execute 99.9% of the time with a try block, and then place error handling code in catch clauses -- code that you don't expect to get executed often, if ever. This arrangement has the nice benefit of making your "normal" code less cluttered.
If you feel that a method doesn't know how to handle a particular error, you can throw an exception from the method and let
someone else deal with it. If you throw a "checked" exception, you enlist the help of the Java compiler to force client programmers
to deal with the potential exception, either by catching it or declaring it in the throws clause of their methods. The fact that Java compilers make sure checked exceptions are handled helps make Java programs more
robust.
When should you throw an exception? The answer can be summed up in one guideline:
If your method encounters an abnormal condition that it can't handle, it should throw an exception.
Unfortunately, though this guideline may be easy to memorize and may sound impressive when you recite it at parties, it doesn't clear up the picture too much. It actually leads to a different question: What is an "abnormal condition?"
That, it turns out, is the 4,000 question. Deciding whether or not a particular event qualifies as an "abnormal condition" is a subjective judgment. The decision is not always obvious. It's one reason they pay you the big bucks.
A more helpful rule of thumb could be:
Avoid using exceptions to indicate conditions that can reasonably be expected as part of the typical functioning of the method.
An abnormal condition, therefore, would be any condition that wouldn't reasonably be expected as part of the "normal functioning" of a method. To help you get a feel for what I mean by "normal functioning of a method," allow me to give a few examples.
As an illustration, consider the FileInputStream and DataInputStream classes from the java.io package. Here is an application that uses FileInputStream to print the text of a file to the standard output:
// In source packet in file except/ex9/Example9a.java
import java.io.*;
class Example9a {
public static void main(String[] args)
throws IOException {
if (args.length == 0) {
System.out.println("Must give filename as first arg.");
return;
}
FileInputStream in;
try {
in = new FileInputStream(args[0]);
}
catch (FileNotFoundException e) {
System.out.println("Can't find file: " + args[0]);
return;
}
int ch;
while ((ch = in.read()) != -1) {
System.out.print((char) ch);
}
System.out.println();
in.close();
}
}
This example shows that the read() method of FileInputStream reports an "end of file has been reached" condition not by throwing an exception, but by returning a special value: -1. In
this method, reaching end of file is considered a "normal" part of using the method. It is not considered an "abnormal" condition.
The usual way to read bytes is to keep on reading them until you hit the end.