It depends if the default value is the right value or not. I see that pattern way too often when it just happens to be the fastest way to make a particular use case work. It just makes it harder to debug other use cases down the road.
What do I mean by the default value being the right value? Well, take an integer field for example. What should it default to? If you said you don't know, give yourself a cookie. If you said zero, that's the right answer for, say, "number of upvotes," but not "seconds until self destruct."
In other words, a correct default value is specific to the field and can be used in all use cases without checking for it. If I have to pepper my code with
if IntegerField == -1, the default not only isn't buying me anything I couldn't get with
null, or even better an option or exception, it's actually hurting me because the check is easier to forget and serious errors are easier to ignore. Why would you forego using the tools which are specifically designed to help programmers in this situation?
However, if I can just write
Upvotes += 1 without worrying about if that field has been used before, and know that it will produce the correct result due to a zero default, then the default is buying me something worthwhile.
The problem with the
SafeReader class you describe is it is making assumptions about fields it knows nothing about. I can think of use cases where it might be handy to include defaults for fields not in a query, but they all involve some other form of validating field names, such as against a schema.
I personally consider anything named
SafeWhatever a code smell. The name strikes me as somewhat Orwellian, because the safety is almost always an illusion. It's like taking down guard rails so a cliff road won't look so dangerous.