Re: How to tell caller of an error if you cant change the signature
of a method
Jan Thom? wrote:
So since the implementation is free to do any error handling strategy that
the implementor deems good enough, i'd say wrapping any exception into a
runtime exception does the job for me. Otherwise the interface (== the
contract between me and the caller) should have stated something else.
That is a valid approach. I suggest that one remember what it "means" to have
an exception, what it means to throw an exception, and the prime importance of
operations, particularly relative to development. Jan's answer typifies this
deep understanding - notice the emphasis on what the *contract* of the
interface is, and the acknowledgment that that contract is by design.
Whatever the implementor does, it must not violate that contract, so it
behooves the author of an implementation to understand the semantics of the
contract.
Throwing a runtime exception in turn is also a signal to client code of the
rethrower. It tells that client code that it made a mistake, under the
programmer's control. "Tsk, tsk, you should not have given that illegal value
(IllegalValueException)." This type of error is for the client programmer, to
help them debug their code.
Checked exceptions tend to be for things the programmer cannot reasonably
control, like the file being deleted by an external process or the certificate
repository suddenly becoming unavailable. That's why the API designer placed
those exceptions in the contract for the method. Because the client
programmer cannot control these events, the API designer ensures that they
must check for them. Logging for this type of exception is vital - it helps
the sysadmin understand the operational fubar and fix it.
Often the semantics of a method that returns a String [], as in the OP's
situation, or equivalently a Collection<String>, disregard the reason why
"nothing" is retrieved. All the client code really cares about is if anything
came back. An empty set is empty whether the database is down or the customer
never shopped there, who cares which? Either way the situation could be
different by the time of the next query. In that case, a value like
Answers.EMPTY (a final value from a hypothetical Answers class) defined as a
String [0] or an unmodifiable new ArrayList<String>(0) would be the sentinel
value returned.
--
Lew