Java Reference
In-Depth Information
public class Formatter {
public static void Format(Batter toFormat) {
System.out.print(toFormat.getName());
System.out.print("\t");
try {
System.out.print(toFormat.getAverage());
} catch (NotEnoughAtBatsException e) {
System.out.println("\t" + "Not enough at-bats to be significant");
return;
}
try {
System.out.print("\t" + toFormat.getOBP());
} catch (NotEnoughAtBatsException e) {
System.out.println("\t" + "Not enough at-bats to be significant");
return;
}
try {
System.out.print("\t" + toFormat.getSlugging());
} catch (NotEnoughAtBatsException e) {
System.out.println("\t" + "Not enough at-bats to be significant");
return;
}
System.out.print("\t" + toFormat.getAtBats());
try {
System.out.println("\t" + toFormat.getTotalBases());
} catch (NotEnoughAtBatsException e) {
System.out.println("\t" + "Not enough at-bats to be significant");
}
}
}
This mixes our error-handling code back in with our mainline code, and produces code that is
less readable than the alternative without an exception mechanism. In our particular example,
the approach is obviously missing an abstraction. This is the mistake of a puppy programmer.
When you encounter such code, you should correct the writer, perhaps by rolling up a news-
paper and swatting the offender. You don't really want to cause pain; you just want to make
sure that this never happens again.
Of course, there are also times when this approach is needed. If the way in which you are go-
ing to respond to an exception is tied not just to the exception but to the context in which the
