posted 17 years ago
Not to show any disrespect for the folks who have brought you this far in this discussion, but...
This is not what exceptions are for, and that's the first thing that people should have told you.
Here's what exceptions are for:
Imagine that there's some code in method A, which wants to query a database. So you call Database.sendQuery(), which calls connectToDatabase(), which calls new NetworkConnection(), which calls getDatabaseServerHostAddress(), which calls calls InternetAddress().lookupByHostName(), which determines that the server name is "TODO -- NEED TO FILL THIS IN LATER". What should lookupByHostName() do? It can't print an error message, because it has no idea if method "A" (remember method "A"?) is part of a GUI program, or Web program, or command-line program. But it can't return an address, since it doesn't have good data.
There are two choices for what it can do: first, it could return a special value, like 'null', to indicate failure. That means every one of the methods above has to check for special error values to indicate failure. That's a lot of checking!
The other choice is to throw an exception, which leaves the method and causes getDatabaseServerHostAddress() to exit, and new NetworkConnection() to exit, and connectToDatabase() to exit, and so on, until we get to method "A", which can catch the exception and learn that the host address is bad. Method "a" knows how to tell the user about the problem.
The important thing about this scenario is that one method throws an exception, and some other method -- often a method way up the call stack -- catches it.
You never throw an exception and catch it in the same method. It's slow, inefficient, and messy. Instead, just use the control structures that Java offers. The "continue" statement skips to the next iteration of a loop; that's exactly what you need here. So...
By the way, the method call "System.exit(0)" will end your program.