Re: When to throw exceptions and when to use System.err?
On 27/03/11 21:20, Merciadri Luca wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Everything is in the title: when would you throw an exception
(possibly with some text) at the place of simply making a
System.err.println(some text) and then a System.exit?
A method should normally throw an exception. In general it's
inappropriate for a method to output anything, unless it is explicit
required. It should almost certainly never exit.
It is the responsibility of whatever code invoked the method to handle
the exception. What it does with it is down to the program logic. It may
be that now is the appropriate time to deal with the exception, in which
case it might output an error message, or exit, or both. Or, if it
doesn't know how to deal with the exception it can pass it back up to a
higher authority. Eventually, if nothing elects to handle it, it will be
passed up to the JVM and that will output a stack trace.
It is clear that when an internal error occurs an exception needs to
be thrown. But if some user arguments are directly rejected by your
code (either of the bad types, or in bad quantity, etc.), and that you
know it, do you need to use only exceptions?
There can be no hard and fast rules. Only the logic of your program, and
the current situation within that program, can determine the appropriate
action to be taken.
For example, when it looks clear to me that
==
try
{
int n = Integer.parseInt(args[0]);
}
catch (NumberFormatException noInteger)
{
System.err.println("Your arg needs to be an int.");
System.exit(1);
}
==
holds,
This sort of action is really only appropriate in command line argument
parsing, when done right at the start of the main program where you can
fail-fast. But if the parsing is done elsewhere it should fail by
exception, and never exit.
For example, take the Apache Commons CLI class
(http://commons.apache.org/cli/) which parses command lines. If you used
that class to parse the command line passed to your program it would not
be inappropriate for it to exit your program if it detected an error.
Neither should it output messages to System.err, it's up to your program
to determine the appropriate destination for error messages, not a class
library. Compare the methods CommandLine.getOptionObject with
CommandLine.getParsedOptionValue. The former has been deprecated because
it output to System.err. Instead getParsedOptionValue throws an
exception, and returns the message in the exception, so the caller can
determine what to do with it.
it is less clear if, say, n, is negative when it is assumed to
be positive. Would you throw an exception in this case?
If the input is in error it probably matters little whether it's because
it's not a number or because it's negative rather than positive. At
least it's not really appropriate for the parser to determine different
courses of action. The decision to throw an exception, or output a
message and exit, depends entirely on where within the overall structure
of your program the parsing is being done, and how your program is
designed to handle faulty user input.
There really cannot be any definitive answer. For example, suppose your
code has already run for an hour, calculating some intermediate results,
and then asks the user for further input to clarify what to do next
based on those results. Would it be appropriate at that time to
completely waste an hour of processing simply because the user input an
incorrect value? If the code is being used as part of a GUI, and the
input comes from a text field, an error message output to System.err
will probably never be seen by the user, and exiting would almost
certainly be inappropriate.
--
Nigel Wade