Best practice for validating values provided to a constructor?

Question

Context: I am writing a semaphore class for school, and one of the requirements is that it may not be initialized with a negative value.

Right now my constructor throws an exception:

/**
 * Constructor
 */
public Semaphore(int value) throws Exception
{   
    if (value < 0)
        throw new Exception("Negative value provided for initial constructor.");
    this.value = value;
}

Handling an exception in order to instantiate a semaphore seems overly heavy to me, so I am considering quietly setting any negative values to zero, ie:

/**
 * Constructor
 */
public Semaphore(int value) 
{   
    if (value < 0)
        this.value = 0;
    else
        this.value = value;
}

There is no single best answer here; it depends ENTIRELY on the needs of the package and its users. — keshlam, Feb 25 '14 at 13:51
I found http://stackoverflow.com/q/6086334/2671237 after reading this - and am now using an IllegalArgumentException (an unchecked exception) — sfyn, Feb 25 '14 at 13:51

Alexis Leclerc · Accepted Answer · 2014-04-03T18:38:17.677

8

You should use the IllegalArgumentException instead. It requires no explicit exception handling and it behaves exactly like you want, that is to signal an illegal argument.

edited Apr 03 '14 at 18:38

answered Feb 25 '14 at 13:51

Alexis Leclerc

1,303
1
16
26

Paolo Fulgoni · Answer 2 · 2014-02-25T14:32:52.763

I suggest to throw an IllegalArgumentException:

Thrown to indicate that a method has been passed an illegal or inappropriate argument.

If your project is using Guava, you could use Preconditions:

public Semaphore(int value) throws Exception
{   
    Preconditions.checkArgument(value < 0,
        "Negative value provided for initial constructor.");

    this.value = value;
}

If the condition evaluates to false, then an IllegalArgumentException will be thrown.

In my opinion, this way the code could be more readable.

score 1 · Answer 3 · answered Feb 25 '14 at 14:05

If you say: Hey, the values are directly from the user. Correct them with a message.

If you say: Hey, the values are generated and a bug produced a negative value.

throw new IllegalArgumentException("Negative Value",
    new IndexOutOfBoundsException(value+""));

If you say: Hey, i like to let the VM decide to throw or correct. Use assert value > 0;.

score -1 · Answer 4 · answered Feb 25 '14 at 16:34

Generally speaking, if you have a project with 1000 classes and each class has 20 functions, thats 20000 functions. Checking input arguments and throwing exceptions for many of the 20000 functions will flood your code with validation checks. I prefer instead to add javadoc to the function saying your input argument to your function cannot be negative (and also, what the function is for). This way, the user (programmer) of your function does not have to examine the content of your function to determine how to use it and what is invalid. Also, his IDE's intellisense will pop up the javadoc message as he is using the function to provide that information. If he violates the javadoc, consider letting the function or one of the functions it calls throw an exception up the the call stack without explicitly doing so, or letting the function not work as expected without throwing an exception. You may consider explicitly thowing an exception if you think providing an invalid input will produce some odd behavior that isn't easy to track down. The javadoc will help him track down the problem without having to specifically throw an exception. Once the business logic is debugged throughly, exceptions being thrown should not happen often unless there is a bug in the business logic.

I don't believe exceptions should be part of validating user input. Your user input should be validated throughly before it gets to the business logic, not when it gets to a business logic function. Same argument about validating an uploaded xml document. Check it against an xml schema before passing it to the business logic. Your validation logic should be based on true/false (validation passed), not on throwing an exception for invalid input.

Best practice for validating values provided to a constructor?

4 Answers4