This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi friends, I wonder that this is so easy question: Suppose your client code is calling a method with some parameters. Is client responsible to check the sanity of passed parameters or that is the responsibility of server (called) object? And if there is any exception encountered in server object, should it throw the exact exception to client side or just wrap it with some more kind message? I've seen this is rather subjective but please lemme know if there is any strict rule in these cases that I am not aware of
Thanks for your reply Paul, In fact I feel there is a misunderstanding about my status. There is not a typical C/S application... When I say client I mean an object in business layer that calls another method in one of its own method. It may be better to name these: Caller and Called instead of Client and Server to emphasize that both of these are server side objects. -Thanks again
In almost any method call you can consider the caller a client and the called a service of some kind, so we can apply this question to "client" and "server" of any scale. Whatever we call things, the called side of the equation should check its incoming parameters. If the validation rules are complex or might change we'd want to have that code in one place, not in every caller. Even if validation is fairly simple, we want the called object to be responsible for maintaining the validity of its own state, not trusting other objects to give it good data.
After saying all that, I don't often have much validation code. I'm trying to figure out why ... maybe invalid data will cause errors that are appropriate and just as useful as an invalid parameter exception? Maybe methods don't often change state? Maybe I'm really lazy? Ok, I have to go away and think now.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 17, 2007
maybe invalid data will cause errors that are appropriate and just as useful as an invalid parameter exception?...
Stan I don't think there is any sort of error that would be appropriate. Error is error and a bad thing if we share terminology Exceptions? There is no clue and those are not so disaster: you can catch them, log them and prepare a appropriate message for end users. Let me know what do you think...
. . . this sounds like a "Design by Contract" [DBC] problem. DBC appears to be a trademark of the Eiffel language; it is discussed here.
What it means is that a method is allowed to check the validity of any arguments passed to it. If the arguments fail the validity check (precondition), then the called method throws an Exception. Look up, for example, the java.awt.Color(int int int) constructors. If you pass the wrong values for the three numbers, the constructor throws an Exception. That means, if there is an error, then the method calling has the error, and it is held responsible for sorting it out. Also in the following Circle class, I have put a precondition in the constructor; you can't have a negative radius.
ALSO: there may be a postcondition. That is something which has to be true at the end of the method. You can have an assertion like in this method, in the Circle class which I have just thought up:- Now there is an assertion at the end of the setArea method, that area equals PI*r^2. The idea of preconditions and postconditions was set out by Hoare in the 1960s; if the precondition is fulfilled, a "correct" method must thereafter fulfil its postcondition in all instances. Note it was not necessary to check precondition and postcondition in every method. If there is a violation of the postcondition, the method needs to be checked on the assumption there is an error in its code.
There is an additional feature which might need to be validated, called the class invariant. In the case of the circle, there are actually two invariants:-
Area equals PI * radius ^ 2, and
Circumference equals 2 * PI * radius.
A more stringent implementation of Circle would calculate the circumference and area in the constructor, and have an invariant method, which can be called in every other method:- Now that class has an invariant at its start, and finish. It has a precondition, and the postcopndition is implicit, being incorporated in the invariant.
That will give a rigorous check of the Circle class, confirming "correctness" at all points, so you can confirm it works properly. You can enable assert statements with the -ea flag on the JVM, so you can run it in a production version missing out the assertions, with faster processing.
PS: Beware of floating point arithmetic. All will be well until you try the square root of 400 and get 19.999999999999999