Ensure valid data or protect against invalid data? Both?

Question

I would like to know, in a practical sense, on a large scale (Java - my case)project is it better to just code defensive logic to protect against invalid data in the DB or just take the time to go through and make sure that you don't accept any invalid data? Remember, the issue here is that there are many cases where a null is ok, and there are many cases where a null isn't, so the case to ensure that there is no invalid data is a non trivial one.

The reason I ask is because I am working on a large project and find myself chasing some nasty null pointer exceptions only to realize that the reason its being thrown is because some obscure property of a large object isnt set. So, I go speak with a Systems Engineer only to realize that in the design, that is supposed to have been set by a user, etc.

Note: please don't attribute these issues to just "poor systems design". Whether or not the design could have been better is not the issue at hand (as obviously any design can be improved). I would like to take this form a point of a view of a developer that has already joined a very advanced project (in terms of time spent and lines of code) and what he should do from this point forward?

Thanks!

**It just occurred to me that many might consider this an opinionated issue? If this is the case then anyone can feel free to make this a community wiki. I'm not sure though. There might be some convention or "good-practice" that many follow that I am unaware of, and subsequently wouldn't be an opinionated question at all, simply a matter of informing me, a new developer, of that practice.

Answer 1

Use database constraints (NOT NULL, for instance) to disallow invalid data in the database by any means and input validation in your Java application code to disallow the user to enter invalid data.

Database constraints alone are not enough because the user should see meaningful validation error messages. And input validation alone is not enough because the data in the database must be in a valid state even if there are errors in the input validation code. Also the data in the database doesn't necessarily have to come from your application.

Answer 2

I tend to write my objects to validate upon construction (mostly my objects are immutable). Setters will validate as well.

Validations include null checks (most common - I try very hard to prevent nulls, and comment code when a null is permissible), some sanity checks on values. These will result in IllegalArgumentExceptions upon failure (usually)

When do I perform these validations ? Not on every object/helper object etc. Usually on some sort of transition between appropriate layers or component sets in my application. A good rule of thumb is that any component that is likely to be reused by a new client will perform validation. So (in your example) the database layer would provide validation, usually independently of other layers (this isn't unreasonable if you think that the different layers of the application represent the data in different forms)

The level of validation depends on the source of that data. e.g. validations are performed most rigorously on user input (e.g. entries in text fields etc.). I'm less rigorous for checking input that would come from (say) a Spring XML configuration.

Validation is enormously important. You're checking your data immediately, not when it's going to cause a problem. That makes life a lot easier (imagine if you accept bad input, serialise the object, deserialise it after a year, and find you can't use it!)

Answer 3

If the user is supposed to enter data that will later be checked for validity you should not accept any of the data until the user completes the required fields. It doesn't make sense to accept incomplete data and write incomplete data to the database.

However, you also need to check the data when you retrieve it from the DB, before you try to either work with it or pass it back to the user. Maybe the data has changed from some external source, maybe the data is just corrupt, but you need to verrify it.

So the real answer is "both times." You need to check it on both ends.