Introduction

Quick, is there anything wrong with this code and, if so, what is it? You can assume that the code is part of a class (it's actually in intro/Action.java) and that the whole class compiles without error:

1 public void actionPerformed(ActionEvent e) {
2      try {
3            if (fileName != null && !doingSaveAs) {
4                   doSave(fileName);
5                   return;
6            }
7            if (chooser == null) {
8                   chooser = new JFileChooser();
9            }
10           int returnVal = chooser.showOpenDialog(theFrame);
11           if (returnVal == JFileChooser.APPROVE_OPTION) {
12                  File file = chooser.getSelectedFile();
13                  if (file.exists() && doingSaveAs) {
14                         int ret = JOptionPane.showConfirmDialog(theFrame,
15                                "File already exists, overwrite?", "File Exists",
16                                JOptionPane.YES_NO_OPTION);
17                         System.err.println(ret);
18                         if (ret != 0);     // "Yes" is the 0th option...
19                                return;
20                  }
21                  doSave(file);
22           }
23     } catch (IOException e1) {
24            error("Can't save file", e1);
25     }
26 }

					  

If you spotted the error in under five seconds, give yourself a quick pat on the back. If you didn't catch it, see lines 18 and 19.^[*] Either way, imagine looking for this error in 10,000 lines of code. Or 100,000 lines. Bugs still exist. And they cause real problems for real people. Our goal as developers should be to minimize the number of bugs in our code. Many tools and techniques have been put forth to achieve this over the years. One of the most promising in recent years is called "pair programming," advocated by the Extreme Programming (XP) movement. This has two developers developing code together on a single workstation, a modern realization of the old adage that "two heads are better than one." If you've never heard of XP, you might want to read more about it at http://www.extremeprogramming.org or on Wikipedia (http://en.wikipedia.org/wiki/Extreme_programming).

^[*] The extra semicolon causes the early return to be always true; the file will never be saved.

But several other tools and techniques will help make code more reliable. Java code is quite amenable to the tool builder's craft. The original Java design team decided to use a standard, cross-platform, documented binary file format as the compiler output, the "class file format." This actually follows from the decision to provide a "write once, run anywhere" language. But for our purposes, it means that tools such as javac and javap, and the class-loading mechanism, and all other tools that work on class files, do not have to be written differently for MS Windows, Mac OS, Unix, and other systems. "Write Tools Once, Use Them Everywhere" might have been the motto for this clever decision.