Hi Dimka,
Some time ago I came across a quote that said something like "if your
country is ruled by a committee, be in that committee" being an expat from a
communist country this quote sounded very unpleasant to me but I think it
fits your question very well. Whenever I find myself in this same kind
dilemma I many times just dive into the Sun JDK API looking for similar
contexts and patterns to resolve the very same problem, they are the
"committee". You might also decide not to comply with the committee e.g. I
don't think that IllegalArgumentException should be used in the JDK in the
way it does now, the right tool should be assertions, because assertions
were added later to the language, I think from 1.4.x most likely this is a
backward compatibility issue.
dimka said:
public String getNameById(long id) {
If there would be anything to throw even if it is a RuntimeException
subclass, you should make it explicit in the method declaration as "throws
XXXException" this will get documented in the javadocs and give your clients
some clue of what could go wrong.
Connection connection = null;
Statement st = null;
try {
connection = getConnection();
st = connection.createStatement();
ResultSet rs = st.executeQuery("SELECT NAME WHERE id=" + id);
if (!rs.next()) {
//--->Here, I can return null, throw RuntimeException, throw
catched exception<---
See how Sun's JPA API resolves a similar issue:
http://java.sun.com/javaee/5/docs/a....html#find(java.lang.Class, java.lang.Object)
In this case they just return null. Now, beware that returning null is one
of the main causes of the very profane NullPointerException. There are ways
around it e.g. using the NullObject pattern but in this case that you return
a String the most sensitive thing to do would be returning null.
http://en.wikipedia.org/wiki/Null_Object_pattern
}
return rs.getString(1);
} catch (SQLException e) {
//--->Here, I can return null, throw RuntimeException, throw
If you see a catch, it is not a good idea to firstly just think what to
re-throw. You should rather first think hard what can you do at that point
to recover to fulfill the client's request. This is precisely the definition
of "Robustness" in Software Engineering "Robustness is the ability of
software systems to react appropriately to abnormal conditions" abnormal
conditions being Exceptions see Object Oriented Software Construction by
Bertrand Meyer.
Now, if there is nothing you can really do and you must really throw or
re-throw an exception, then from the design prospective it is not a good
idea to let the client of this code deal with inners of the persistence API,
the SQLException. You should rather throw to the client a more "service"
level-like exception e.g. PersonNotFoundException or at most DaoException
More on checked vs unchecked:
In EJB 3.0 the choice of checked vs. unchecked exceptions has strong
semantics compared to how it was before i.e. checked exceptions are assumed
by the EJB 3 specification to be "application exceptions" and when thrown
they will not rollback the transaction. Unchecked exceptions are assumed
"system exceptions" and when thrown they will cause the transaction to
rollback and even get the container to discard the Bean instance without not
even chance for disposal lifecycle callbacks i.e. @PreDestroy
I am not particularly fond of checked exceptions but I think this would be a
valid strategy to decide what the type of an exception should be. In a
"design by contract" approach a method would look like:
pre-conditions: conditions that the client must respect for the method to
fulfill its service e.g. arg1 must not be null
Method(arg1)
class-invariants: conditions that should be invariant during the lifetime of
an instance of the class
post-conditions: conditions or guarantees of the service offered by the
method e.g. in the case above that the name was found and is a valid name
not an empty string
Checked exceptions: because they force the client of the routine to handle
it, I would only make the client handle situations that they have control of
i.e. the pre-condition. The client is responsible for passing valid input,
so if they do not, they must be ready to fix it and retry. But notice that
the committee in this case decided IllegalArgumentException should be
unchecked and I don't blame them for that.
Unchecked exceptions: to signal that the Method could not fulfill its
promise, the client can do little about this, exactly the situation depicted
above. What can the client of "getNameById" possibly do with a SQLException?
nothing! If the client tried to fix it that would mean that the client would
be trying to do "getNameById"'s job in some way and this would break the
clean distribution of concerns leading to:
- tangled code: the client will not only implement business logic but also
low level persistence non-functional concerns
- scattered code: the same non functional concern is spread across many
disparate parties: Client, Dao, etc the right recipe for a nice spaghetti.
HTH,
Best regards,
Giovanni
