Ensure valid data or protect against invalid data? Both?
<p>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. </p>

<p>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. </p>

<p>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). <strong>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?</strong></p>

<p>Thanks!</p>

<p>**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. </p>
