goto Considered Helpful
Friday, December 15th, 2006 11:57 amSave me Edsgar! I just wished I could use a
goto statement in Java. My code's primary purpose is to take a bunch of fixed-width data and save it to another file in a tab-delimited format. I decided to add the ability to save the layout. If the layout file already exists, I prompt the user with a Yes/No/Cancel dialog to overwrite. If they cancel, I don't want to write anything (layout or data) and just return from the function. If they say no, I won't write the layout file, but I still need to write the data. If they say yes, or if the file didn't already exist, I write the layout file and then write the data. With a goto, I could break out of my if conditions and just write the data. But without the goto, my options are to set a status flag, write a function to prompt and write the layout, returning a boolean if it was canceled so I can refrain from writing data (probably the best solution), or the following solution: write a one-iteration for loop and break to a label, like so:
if (verifyInputFile() && verifyOutputFile()) {
if (StringUtilities.isNotEmpty(saveLayoutField.getText())) {
gotohack: for (int hack = 0; hack == 0; ++hack) {
File layoutFile = new File(saveLayoutField.getText());
if (layoutFile.isDirectory()) {
layoutFile = new File(layoutFile, viewLinker.getInputFile().getName() + ".layout.txt");
}
if (layoutFile.exists()) {
int choice = OptionDialog.showStandardYesNoCancelDialog(parent, "Layout file " + layoutFile + " exists. Overwrite?");
if (choice == OptionDialog.CANCEL) {
return;
}
if (choice == OptionDialog.NO) {
break gotohack; // because Java can't goto the run call
}
}
try {
PrintWriter writer = new PrintWriter(new FileOutputStream(layoutFile));
for (Iterator iter = fieldModel.iterator(); iter.hasNext();) {
Field field = (Field) iter.next();
writer.println(field.name + "\t" + field.length);
}
writer.close();
} catch (Exception e) {
parent.handleException("Could not write layout file " + layoutFile, e);
}
}
}
writeData();
}
Sez Linus:
Date: 2006-12-16 01:29 am (UTC)Subject: Re: any chance of 2.6.0-test*?
Date: Sun, 12 Jan 2003 12:22:26 -0800 (PST)
On Sun, 12 Jan 2003, Rob Wilkens wrote:
> However, I have always been taught, and have always believed that
> "goto"s are inherently evil. They are the creators of spaghetti code
No, you've been brainwashed by CS people who thought that Niklaus Wirth
actually knew what he was talking about. He didn't. He doesn't have a
frigging clue.
> (you start reading through the code to understand it (months or years
> after its written), and suddenly you jump to somewhere totally
> unrelated, and then jump somewhere else backwards, and it all gets ugly
> quickly). This makes later debugging of code total hell.
Any if-statement is a goto. As are all structured loops.
Ans sometimes structure is good. When it's good, you should use it.
And sometimes structure is _bad_, and gets into the way, and using a
"goto" is just much clearer.
For example, it is quite common to have conditionals THAT DO NOT NEST.
In which case you have two possibilities
- use goto, and be happy, since it doesn't enforce nesting
This makes the code _more_ readable, since the code just does what
the algorithm says it should do.
- duplicate the code, and rewrite it in a nesting form so that you can
use the structured jumps.
This often makes the code much LESS readable, harder to maintain,
and bigger.
The Pascal language is a prime example of the latter problem. Because it
doesn't have a "break" statement, loops in (traditional) Pascal end up
often looking like total shit, because you have to add totally arbitrary
logic to say "I'm done now".
Linus