Re: Understanding Exceptions
Steve Crook wrote:
I'm in the process of learning Java and would appreciate a bit of
guidance on the correct way to handle exceptions.
Others have answered brilliantly with respect to why this particular situation
requires a 'java.security.NoSuchAlgorithmException' particularly. I will
presume to broaden the scope to exceptions slightly more generally, and to the
unchecked (RuntimeException) vs. checked (non-RuntimeException) conundrum.
...
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.
Not necessarily - every method is required to handle that exception, but that
doesn't always mean to rethrow it. Usually it's catch-log!-convert-depart.
Most of the time we programmers should avoid 'Throwable's above and including
'Exception', preferring (nearly) always a proper subtype of 'Exception' in
code we write. (The use of 'assert' is a separate topic.)
Conceptually you were right the first time, Steve -
... thefalse premise that the exception could never occur.
The whole point of an exception is that it *should* never occur, but it does
anyway. The exception mechanism assures that the environmental structure is
correct. Any failure in an exception-reportable condition disables the
program, and the exception mechanism lets us detect, report and recover from
such failures gracefully. Moreover exceptions pose little overhead for the
"happy path" of algorithmic satisfaction, only kicking in when some dependency
goes awry.
Checked exceptions, those that are not subtypes of 'RuntimeException', must be
declared in the signature of any method that throws them. This is to enforce
awareness of algorithmic dependencies on the caller. The proper response to a
checked exception is to catch it, log it! and take an error departure from the
current program state, typically to a report-then-restartorexit state.
An API requires checked exceptions to ensure the happy path through
predictable or uncontrollable failures, like 'java.io.IOException' or the
aforementioned 'java.security.NoSuchAlgorithmException'. Unchecked
exceptions, that is, 'RuntimeException' and its subtypes, do not appear in a
method signature because they are really not supposed to happen. A runtime
exception is a symptom of programmer error, not resource or environment
trouble. A few runtime exceptions, notably 'ClassCastException' and
'NullPointerException' and their ilk, are more common but they still must be
handled so as not to disrupt program flow in production.
An API throws 'IllegalArgumentException', 'IllegalStateException' or other
runtime exception either for situations that programmers must not allow, or to
wrap checked exceptions and propagate them to a default handler mechanism.
Either way, one throws a runtime exception to signal a situation that must be
handled before a program can successfully deploy and operate.
In an nutshell, a checked exception is one that needs to be part of the method
contract, a runtime exception is one that really should be prevented.
--
Lew