views:

318

answers:

3

Possible Duplicate:
When to choose checked and unchecked exceptions

Hello!

So, I'm still getting comfortable regarding when to throw a checked or unchecked exception. I would like to know what others think is the most appropriate in this case:

class Correlation<T>
{
    private final T object1, object2;
    private final double correlationCoefficient;

    public Correlation(T object1, T object2, double correlationCoefficient)
    {
     if(Math.abs(correlationCoefficient) > 1.0 || (object1.equals(object2) && correlationCoefficient != 1.0))
      throw new IllegalArgumentException();

     this.object1 = object1;
     this.object2 = object2;
     this.correlationCoefficient = correlationCoefficient;
    }
}

So, in this case, I would like to throw a runtime exception because I cannot easily recover from a situation where the user passes in bad data. I would like to point out beforehand that I have no control over the data being passed in. If I could, I would create an interface which guarantees that the conditional in the constructor is true. However, this is a convenience class for correlations that have already been computed, so I have to trust that the user is providing accurate information.

Okay, let me know what you all think!

+3  A: 

In my opinion, the answer hinges on:

  • Do you expect the caller to be able to recover gracefully?
  • Is this API intended for public or internal consumption?

Someone people will tell you that you should never use checked exceptions. That's purely subjective.

Chase Seibert
+5  A: 

I think this is the correct response. You are effectively doing barrier asserts, i.e. barrier checks, and if they are wrong you are refusing to create the entity. I would document with a java doc that you can throw an IllegalArgumentException, however outside of that, it looks correct.

Joshua Block has some great information regarding checked and unchecked exceptions. The basic premise is that, unless you absolutely want someone checking for the exception, you should throw an unchecked exception. Thinking this way can complicate some coding and return values, but in general it makes for cleaner, more efficient code. Use exceptions for exceptional cases, and things will work better for you.

Just my 2 cents.


Edit

Just to be clear, here is something like the java doc you should have:

/**
 * <Something describing constructor, and what it does, ending with a period.>
 *
 * @param parameter <Describe the parameter - do one for each parameter of the constructor,
 *     and note which values may be illegal for that particular parameter.>
 * @throws IllegalArgumentException <the case for the illegal argument exception.>
aperkins
+2  A: 

You should ALWAYS include an explanatory text in your exception. In this particular case you might even consider have TWO checks:

    if(Math.abs(correlationCoefficient) > 1.0)
            throw new IllegalArgumentException("abs(correlationCoefficient) > 1.0 - " + correlationCoefficient);
    if((object1.equals(object2) && correlationCoefficient != 1.0))
            throw new IllegalArgumentException("object1==object2, but correlationCoefficient != 1.0, " + correlationCoefficient);

This allows those who actually get to see the stacktrace to be able to identify the exact cause without having to look intimately at the code. A given exception should only be triggered by ONE condition, not several, since you will not be certain what happended. Also include all necessary information as this may be crucial if the error situation cannot be reproduced in a test scenario.

Thorbjørn Ravn Andersen
Yes, ALWAYS have an exception message that explains the exception and contains the values that resulted in it.
Software Monkey