Who should verify the sanity of data?

[Ashkan Roshanayi]

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

-Regards

[Paul Sturrock]

Generally it is the server that contains an application's business logic, so it is the server that should ultimately handle validation. However, there are secondary validation mechanisms that can be useful, for example JavaScript validation in a web application can check whether a field is null without making a request to the server, so its a handy mechanism for some quick, inexpensive checks. However its not to be relied on, the server should usually be validating data as if it has no knowledge of the client application.

[Ashkan Roshanayi]

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

[Stan James]

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.

[Ashkan Roshanayi]

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...

[Campbell Ritchie]

. . . 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:-

import static java.lang.Math.PI;
 
public class Circle
{
   private double radius, area, circumference;
 
   public Circle(double radius)
   {
      if(radius < 0) throw new IllegalArgumentException("Negative radius not acceptable");
      this.radius = radius;
   }// end constructor
 
. . . .
   public double getArea()
   {
      return PI * radius * radius;
   }// end get area
 
   public void setArea(double area)
   {
      radius = Math.sqrt(area / PI);
      assert area == PI * radius * radius;
   }// end set area
}//end class

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:-

. . .
public void setArea(double area)
{
   assert invariant();
   if(area <= 0) throw new IllegalArgumentException("Negative or zero area not acceptable");
   radius = Math.sqrt(area / PI);
   this.area = area;
   circumference = 2 * radius * PI;
   assert invariant();
}// end set area
/*   Similarly in other methods   */
private boolean invariant()
{
   return(area == PI * radius * radius && circumference == 2 * PI * radius);
}// end invariant
. . .

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.

CR

PS: Beware of floating point arithmetic. All will be well until you try the square root of 400 and get 19.999999999999999