One part of my program fetches data from many tables and columns in my database for processing. Some of the columns might be null, but in the current processing context that is an error.
This should "theoretically" not happen, so if it does it points to bad data or a bug in the code. The errors have different severities, depending which field is null; i.e. for some fields the processing should be stopped and somebody notified, for others the processing should be allowed to continue and just notify somebody.
Are there any good architecture or design principles to handle the rare but possible null entries?
The solutions should be possible to implement with Java but I didn't use the tag because I think the problem is somewhat language-agnostic.
Some thoughts that I had myself:
Using NOT NULL
Easiest would be to use a NOT NULL constraint in the database.
But what if the original inserting of the data is more important that this later processing step? So in case the insert would put a null into the table (either because of bugs or maybe even some valid reason), I wouldn't want the insert to fail. Let's say that many more parts of the program depend on the inserted data, but not on this particular column. So I would rather risk the error in the current processing step instead of the insert step. That's why I don't want to use a NOT NULL constraint.
Naively depending on NullPointerException
I could just use the data as if I expect it to be always there (and that should really be the case), and catch resulting NPEs at an appropriate level (e.g. so that the processing of the current entry stops but not the whole processing progress). This is the "fail fast" principle and I often prefer it. If it is a bug at least I get a logged NPE.
But then I lose the ability to differentiate between various kinds of missing data. E.g. for some missing data I could leave it out, but for others the processing should be stopped and an admin notified.
Checking for null before each access and throwing custom exceptions
Custom exceptions would let me decide the correct action based on the exception, so this seems like the way to go.
But what if I forget to check it somewhere? Also I then clutter my code with null checks which are never or rarely expected (and so definitely not part of the business logic flow).
If I choose to go this way, what patterns are best suited for the approach?
Any thoughts and comments on my approaches are welcomed. Also better solutions of any kind (patterns, principles, better architecture of my code or models etc.).
Edit:
There is another constraint, in that i am using an ORM to do the mapping from DB to persistence object, so doing null checks on that level would not work (as the same objects are used in parts where the null does not do any harm). I added this because the answers provided so far both mentioned this option.
Best Answer
I would put the null checks in your mapping code, where you build your object from the result set. That puts the checking in one place, and won't allow your code to get halfway through processing a record before hitting an error. Depending on how your application flow works, you might want to perform the mapping of all the results as a pre-processing step instead of mapping and processing each record one at a time.
If you're using an ORM then you'll have to perform all your null checks before processing each record. I'd recommend a
recordIsValid(recordData)-type method, that way you can (again) keep all the null-checking and other validation logic in one place. I definitely wouldn't intermingle the null checks with the rest of your processing logic.