2

Let's say I have a class like the following one:

public class Parameter {

private double[] parameterValues;

public Parameter(double[] parameterValues) throws BadElementInitializationException {

    checkParameterValues(parameterValues);
    this.parameterValues = parameterValues;
}

public double[] getParameterValues() {
    return parameterValues;
}

public void setParameterValues(double[] parameterValues) throws BadElementInitializationException {

    checkParameterValues(parameterValues);
    this.parameterValues = parameterValues;
}

private void checkParameterValues(double[] parameterValues) throws BadElementInitializationException {

    if(parameterValues == null)
        throw new BadElementInitializationException("Parameter values cannot be null");
    if(parameterValues.length == 0)
        throw new BadElementInitializationException("Parameter values cannot be empty");
}

public int noOfValues(){
    return parameterValues.length;
}

}

And the array is later used to perform some calculations.

My question is, where should I check that parameterValues is not null, nor empty? Should I do that in the Parameter class, like I did, or should I do that in the class which performs calculations?

Moreover, should I throw an exception here, or in the Calculation class? And what would be the reason to throw checked and what to throw unchecked exception? My goal is to make a stable application that won't crash easily.

Kobe-Wan Kenobi
  • 3,694
  • 2
  • 40
  • 67
  • I suggest to have the Parameter class as same and handle the exception in the calculation class. So that you can define the handling mechanism based on the scenario which extends the parameter class. – Aravindhan Dec 11 '15 at 10:55

2 Answers2

2

You should do it in all places where getting an null or empty array is not valid. If you do it just in your Parameter class and rely on this having done the check in your Calculator class, then what if you start to use your Calculator class somewhere else? Who are you going to rely on to do the checks there? If you do it in the Calculator class and then refactor the Parameters class to use something else in the future, then your check will go away.

If its also invalid to have a null or empty array in your Calculator class then you need to check there as well.

Alternatively pass an object to both which cannot be empty and then you only need to make the null check.

Sam Holder
  • 32,535
  • 13
  • 101
  • 181
  • Thank you for your answer, it is quite useful. I finally accepted your answer since you provided more arguments and mentioned possible future problems. I thougth that it's an overkill to check it in both places, but know I'm fine with it. Do have any comments about type of exception to throw? – Kobe-Wan Kenobi Dec 11 '15 at 11:54
  • You should throw a standard exception (in java I believe that is IllegalArgumentException) or you should throw a specific exception which derives from that. Personally I think that checked exceptions are a design mistake in Java, so I would avoid them, but YMMV as this is mostly personal opinion. – Sam Holder Dec 11 '15 at 12:01
1

Should I do that in the Parameter class, like I did, or should I do that in the class which performs calculations?

In my opinion, better to check in Parameter class then any other classes. You could see how it do in google guava , for example, in most class they use:

  public static boolean isPowerOfTwo(BigInteger x) {
    checkNotNull(x);
    return x.signum() > 0 && x.getLowestSetBit() == x.bitLength() - 1;
  }

 or

public static int log2(BigInteger x, RoundingMode mode) {
     checkPositive("x", checkNotNull(x));
     ...

Moreover, should I throw an exception here, or in the Calculation class?

If you check your parameters in Parameter class, better throw in Parameter class also. In addition to, you may use some standart function to check and throw exception, for example from google guava:

  com.google.common.base.Preconditions.checkNotNull
  com.google.common.base.Preconditions.checkArgument 
  com.google.common.math.MathPreconditions.checkPositive

And what would be the reason to throw checked and what to throw unchecked exception?

A checked exception is good if you think that you must catch and working this exception later. In most case, for wrong parameters quite enough unchecked exception, like standart IllegalArgumentException in Java. Also, a checked exception need to say other programmers (who use this API) that this exception could be happened, and they need to working with it. Working with an unchecked exception is quite easy for programmer (and often reduce your source code), however a checked exception become your code is more reliable.

A more info about checked and uncheked exceptions, you could find in this post

Community
  • 1
  • 1
Slava Vedenin
  • 58,326
  • 13
  • 40
  • 59