Re: Understanding Exceptions
Sun, 07 Nov 2010 08:05:16 -0800, /Patricia Shanahan/:
Stanimir Stamenkov wrote:
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) {
throw new AssertionError(nsae);
}
}
You should not "swallow" the original exception as causing the program
to continue as if there was no error and returning a bogus result would
cause more severe errors for your application.
I agree with most of this, but would prefer an Exception extending
RuntimeException to AssertionError. Shouldn't AssertionError mean that
an assertion has failed, not some other unexpected condition? I would be
surprised to see it in a run with assertion checking disabled. An Error,
rather than an Exception, seems a bit drastic for something that may be
recoverable by skipping a single file or using a different algorithm.
I'm not sure AssertionError is the best type of throwable to use,
but throwing an Error rather than a RuntimeException in such
situations certainly makes sense to me. It depends on how one would
measure the severity of the problem. If the problem would cause
multiple failures per second and generally causing no useful result
out of the application, I would rather indicate that with an Error -
I've picked up AssertionError as I didn't want to introduce yet
another type of Error, and it seemed reasonable enough to use.
--
Stanimir