Should you check for wrong parameter values in the constructor?

Question

Do you check for data validity in every constructor, or do you just assume the data is correct and throw exceptions in the specific function that has a problem with the parameter?

Answer 1

A constructor is a function too - why differentiate?

Creating an object implies that all the integrity checks have been done. It's perfectly reasonable to check parameters in a constructor and throw an exception once an illegal value has been detected.

Among all this simplifies debugging. When your program throws exception in a constructor you can observe a stack trace and often immediately see the cause. If you delay the check you'll then have to do more investigation to detect what earlier event causes the current error.

Answer 2

It's always better to have a fully-constructed object with all the invariants "satisfied" from the very beginning. Beware, however, of throwing exceptions from constructor in non-managed languages since that may result in a memory leak.

Answer 3

If you throw in the constructor, the stack trace is more likely to show where the wrong values are coming from.

Answer 4

I agree with sharptooth in the general case, but there are sometimes objects that can have states in which some functions are valid and some are not. In these situations it's better to defer checks to the functions with these particular dependencies.

Usually you'll want to validate in a constructor, if only because that means your objects will always be in a valid state. But some kinds of objects need function-specific checks, and that's OK too.

Answer 5

I always coerce values in constructors. If the users can't be bothered to follow the rules, I just silently enforce them without telling them.

So, if they pass a value of 107%, I'll set it to 100%. I just make it clear in the documentation that that's what happens.

Only if there's no obvious logical coercion do I throw an exception back to them. I like to call this the "principal of most astonishment to those too lazy or stupid to read the documentation".

Answer 6

This is a difficult question. I have changed my habit related to this question several times in the last years, so here are some thoughts coming to my mind :

• Checking the arguments in the constructor is like checking the arguments for a traditional method... so I would not differentiate here...
• Checking the arguments of a method of course does help to ensure parameters passed are correct, but also introduces a lot of more code you have to write, which not always pays off in my opinion... Especially when you do write short methods which delegate quite frequently to other methods, I guess you would end up with 50 % of your code just doing parameter checks...
• Furthermore consider that very often when you write a unit test for your class, you don't want to have to pass in valid parameters for all methods... Quite often it does make sense to only pass those parameters important for the current test case, so having checks would slow you down in writing unit tests...

I think this really depends on the situation... what I ended up is to only write parameter checks when I know that the parameters do come from an external system (like user input, databases, web services, or something like that...). If data comes from my own system, I don't write tests most of the time.

Answer 7

I always try to fail as early as possible. So I definitively check the parameters in the constructor.

Answer 8

In theory, the calling code should always ensure that preconditions are met, before calling a function. The same goes for constructors.

In practice, programmers are lazy, and to be sure it's best to still check preconditions. Asserts come in handy there.

Example. Excuse my non-curly brace syntax:

// precondition b<>0
function divide(a,b:double):double;
begin
  assert(b<>0); // in case of a programming error. 
  result := a / b;
end;

// calling code should be:
if foo<>0 then
  bar := divide(1,0)
else
  // do whatever you need to do when foo equals 0

Alternatively, you can always change the preconditions. In case of a constructor this is not really handy.

// no preconditions.. still need to check the result
function divide(a,b:double; out hasResult:boolean):double;
begin
  hasResult := b<>0; 
  if not hasResult then
    Exit;
  result := a / b;
end;

// calling code:
bar := divide(1,0,result);
if not result then
  // do whatever you need to do when the division failed

Answer 9

Always fail as soon as possible. A good example of this practice is exhibited by the runtime .. * if you try and use an invalid index for an array you get an exception. * casting fails immediately when attempted not at some later stage.

Imagine what a disaster code be if a bad cast remained in a reference and everytime you tried to use that you got an exception. The only sensible approach is to fail as soon as possible and try and avoid bad / invalid state asap.