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

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!)