- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Just guessing how that might have happened: an older version of the application accepted null values that still exist in the database, requiring the nullable property type. In the current version, only non-null values are allowed and the .Value is used to inforce that even though validation would have been the better approach?
Also: Nullable<First>
Admin
In this example, you get a warning (or an error if you want to enforce it) when you access a member of a nullable object without checking for null's first.
Admin
Maybe the attribute is nullable to handle some legacy data in the database, but new values are not expected to be NULL.
Admin
I agree with everyone. I’ve done this myself with an ORM. We can’t use general validation, because we still need to update existing rows without changing the null column. But at the same time, we will never set that column to null, and if someone tries, we need to throw an error.
The only real WTF is that there isn't a more vocal exception raised.
Admin
As a shout up to the heavens, I suggest that the coloring that the IDEs do should somehow colorize or format nullable values in a special way so developers know when they're dealing with one.
Admin
Many, many moons ago, way back in the dawn of time, I was working on a system that was built on the Forte 4GL system. (I told you it was many moons ago, way back in the dawn of time.) That system had a pretty comprehensive set of types: dates, times, strings, integers, etc. All of them in both a Nullable and non-nullable form.
The thing is, the TOOL programming language that Forte used was object oriented. Which is fine. But the nullable types... inherited from the non-nullable types. Meaning that if you had code that used the nullable types, you HAD to pass in the data in the nullable type, even if it came from a non-nullable source. Whereas if you had code that used the non-nullable types, you could pass in the data in either type. Meaning that the type enforcing did a very poor job of it when it came to data that was SUPPOSED to never be null.
I really don't miss that job. Or that system. There were some nice ideas in there, but it was very clear to me that it wasn't going to go anywhere in the marketplace. (And it didn't; Sun pulled the pin on support in 2009, about ten years after I quit that job.)