Re: Understanding Exceptions
Stanimir Stamenkov wrote:
And then 'NoSuchAlgorithm' is implementation detail of the OP's method,
Lew wrote:
No, it is not. The 'java.security.NoSuchAlgorithmException' is part o=
f
the method signature of 'java.security.MessageDigest.getInstance()',
which is part of the standard API and most definitely not the OP's metho=
d.
Stanimir Stamenkov wrote:
The OP's method invokes
java.security.MessageDigest.getInstance(String), and the invocation
is part of the OP's method implementation. I don't know what you're ta=
lking about.
You just restated my point, so you must know what I'm talking about.
The 'NoSuchAlgorithmException' is a part of the method signature of
the Java API that the OP uses, saving himself the trouble of
reinventing the wheel. You seem to be talking about a propagation of
that exception, though I don't know why you would. I for one have not
recommended that the OP propagate the 'NoSuchAlgorithmException'. I
have, and I restate yet again, recommended "catch, log! and take
alternate logic path".
Whether the OP's method uses the standard Java API
for its implementation, or it is implementing the result entirely on
its own, is irrelevant to the OP's API, or at least he may wish to
keep that detail independent from the actual implementation.
OK. And ...?
The fact that the OP uses the standard Java API is very relevant - it
means that he must use the API in accordance with its method
signatures, which include checked exceptions. Ergo, his code must
handle those exceptions. He does not get a choice in what exceptions
that API throws. He also does not get a choice in what type arguments
the methods accept nor what they return. He must use the API as
presented or not at all.
You seem to be talking aboiut what exceptions or errors, if any, the
OP's code should throw in response to that exception. Were it up to
me I'd either wrap the checked exception in an unchecked exception and
throw that, if the failure were dire enough, or I'd gracefully return
from the method with another appropriate failure condition. Either
way, the calling code for that method in turn would have to direct the
application to an appropriate error-handling module. None of this has
any bearing whatsoever on the fact that the standard Java API itself
throws an appropriate checked exception when you ask it to provide an
algorithm not present in the environment.
Stanimir Stamenkov wrote:
which he presumably don't want to expose as an API, or at least not as
Not relevant to my point.
Lew wrote:
The Java API writers already exposed it as an API,
Stanimir Stamenkov wrote:
checked exception. But he might consider the lack of a particular
Lew wrote:
... as a checked exception. That ship has already sailed.
Stanimir Stamenkov wrote:
The OP may not want to have 'java.security.NoSuchAlgorithmException'
infested his entire code just to make it possible to only "handle"
it at a top-level (dumping the exception stack trace or just its
message) - is that an impossible variant to you?
Huh? How does handling an exception "infest ... his entire code"?
WTF are you talking about?
The OP is calling a library that throws a checked exception. That, by
the API designer's intent, requires the OP's code to handle the
exception. Period. The OP did not write the API call, so they have
to accept the (correct) decision by that API to throw a checked
exception. What the OP does to handle that checked exception is the
standard thing: catch, log! and take an error path in the code
thence. That's normal and standard, no "infestation" involved.
None of which changes the fact that the checked exception in question
is most assuredly not an "implementation detail of the OP's method"
but of the standard Java API itself. If you want to use the API, and
the OP should want to, then you have to deal with the API's
requirements.
Stanimir Stamenkov wrote:
algorithm implementation more than a serious failure which could break
the entire system/application, so is using Error instead of
RuntimeException type in such case generally permissible (not ruled out
completely), if the author thinks it would be better this way?
What the OP chooses to do with the exception is another matter. All I
was saying is that the low-level routine that looks for the algorithm,
'MessageDigest.newInstance()' in this case, should (and does) throw a
checked exception.
Hence I stated,
He might think it is, but the actual author chose to expose it as a
checked exception, the correct approach.
I think you were misinterpreting my point - that the appropriate
response for the low-level routine ('newInstance()') to a missing
resource is a checked exception - to imply that the OP's code should
throw a checked exception. I did not say that. I spoke of responses
to a missing resource; you spoke of responses to a checked exception.
As to how to handle a checked exception, turning it into an 'Error' is
a step in the utterly wrong direction. You shouldn't respond to a
drastic event with a more drastic event but a less drastic one. The
code can rewrap in an unchecked exception on the assumption (i.e.,
guarantee) that upstream code will convert that in turn to an even
less drastic code path. Or it can log! and eat the exception,
responding with an alternate return path that leads to error-condition
handling. Under nearly no circumstances is a BLAAAAT! [stacktrace]
response an ideal way to handle problems.
So to summarize my points, not the ones you attempted to refute but
the actual points:
- handle missing resources with a checked exception from the lowest-
level routine (such as 'MessageDigest.newInstance()').
- handle checked exceptions (at the next level up) with catch-log!-
wraporeat-alternate_return.
- handle unchecked exceptions with catch-log!-eat-alternate_return.
- handle out-of-band situations gracefully, not with an 'Error' or
other program-crashing technique.
- The exclamation point in "log!" is meaningful.
--
Lew