Re: Understanding Exceptions
On 11/7/2010 8:27 AM, Steve Crook wrote:
Hi all,
I'm in the process of learning Java and would appreciate a bit of
guidance on the correct way to handle exceptions.
The element of code I'm working on is a simple sha2-256 hash:
private static String sha256(byte[] password, byte[] iv) {
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(iv);
byte[] hash = md.digest(password);
return byteArrayToHexString(hash);
}
During compile this throws an unreported exception
java.security.NoSuchAlgorithmException. This in itself seems odd to me
because there is such an Algorithm as "SHA-256".
But is it registered on your system? A lot of crypto things
are done this way: Implementations are provided independently of
your code, are given names like "SHA", and are deposited in some
well-known place. At run time you ask for "SHA-256", the crypto
framework tries to find it in the well-known places and retrieve
it, and throws up its hands if it can't. The presence or absence
can't be determined at compile time, not even in principle. The
system administrator could register (and de-register!) crypto
implementations long after the program has been compiled, changing
the conditions under which the program runs. The existence of
"SHA-256" is like the existence of a file named "data.txt.23-Oct":
*you* may believe that it'll be there, but there are no guarantees.
... but what you're really asking about isn't what might cause
the particular exception, but what to do once it's thrown. Onward:
One means to handle the exception is:
private static String sha256(byte[] password, byte[] iv)
throws NoSuchAlgorithmException {
This appears to be a nasty solution however because every method that
calls this method is then also required to throw the same exception.
... or to cope with it in its own way.
Better seems to be to catch the exception with something like:
private static String sha256(byte[] password, byte[] iv) {
try {
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(iv);
byte[] hash = md.digest(password);
return byteArrayToHexString(hash);
} catch (NoSuchAlgorithmException nsae) {
}
}
An exception usually indicates that something "exceptional" has
happened, and it's seldom a good idea to just ignore the fact. When
your car throws the OutOfGasException, you can no longer drive. You
may think "I'm sure my teenage son refilled the tank before coming
home last night," but you must be prepared for the possibility that
he didn't.
Now I've solved one problem and created another because the compiler
complains that I'm missing a return (which is true). I can insert a
false one, as in:
private static String sha256(byte[] password, byte[] iv) {
try {
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(iv);
byte[] hash = md.digest(password);
return byteArrayToHexString(hash);
} catch (NoSuchAlgorithmException nsae) {
}
return "foobar";
}
This seems downright ugly though and is probably also evil. As the
exception never happens though, because there is such an algorithm as
"SHA-256", perhaps it is correct. Argh, brain ache! :)
Any advice would be much appreciated.
Three broad approaches suggest themselves (others may taxonomize
things differently):
1) Declare your method with "throws NoSuchAlgorithmException" and
require the caller to cope. This may seem onerous, but consider: the
caller usually knows more about the overall state of the application
than the lower-level callee, and as such may be in a better position
to decide what to do.
2) Try something else. This may not be applicable in this case,
since your method's name suggests that its purpose is fairly narrowly
circumscribed, but some methods may have alternatives. For example,
imagine a method that reads configuration information from a file, but
falls back on defaults if the file doesn't exist. In light of (1),
imagine your sha256() method being called from a makeMessageDigest()
method, which will use SHA-256 if it can or fall back on CRC-4242
if it can't. Such an upper-level method uses approach (2).
3) For a "Can't happen, no substitutes anyhow" situation, you can
wrap the checked exception in an unchecked exception and throw the
latter:
private static blah(Blah blabla) // no "throws"
{
try {
thisAndThat();
}
catch (NoSuchAlgorithmException nsa) {
throw new IllegalStateException(nsa);
}
}
The magic here is that IllegalStateException (or any other descendant
of RuntimeException) need not be declared in the method signature, so
callers are not obliged to catch it -- they can, if they like, but they
aren't forced to. In the unlikely event that NSA does in fact get
thrown, this approach packages it inside an ISA (or whatever) and re-
throws it; it will then propagate outward until it's caught by Java
code or eventually by the Java environment, which will deal with it by
printing an informative stack trace (including the original NSA) and
terminating your program.
A fourth broad approach one sometimes sees is
0) Do something drastic, like call System.exit(). IMHO the use of
this approach is the hallmark of an incompetent (and lazy) programmer.
Don't Do That.
--
Eric Sosman
esosman@ieee-dot-org.invalid