A shapefile stores attributes in dBase III format. That format stores everything as ASCII text strings. Although these are perfectly capable of containing some kind of code for null values, no convention ever developed for this. Accordingly, most software for reading and writing dBase files interprets non-numeric ASCII text within numeric fields either as an error or--far worse!--as zero. E.g., ESRI software has shown that it can distinguish empty numeric fields from zeros and treat them as nulls, but somehow it eventually converts any empty numeric values to zeros, so you cannot rely on it. (Because the shapefile is originally an ESRI format and many, if not most, shapefiles will be processed by ESRI software at some point, this means that nobody can rely on using empty values for nulls in shapefiles.)
There are some solutions, all workarounds:
Use a different physical format for the dataset, such as a geodatabase, which supports nulls.
Adopt your own convention for representing null values, as discussed at http://gis.stackexchange.com/a/9801. (This will not work for Boolean fields but is effective for dates and numeric fields.)
If either all or none of the fields will simultaneously be null, create them in a separate table and join that table to the shapefile. Represent a null (which is effectively a null record, by assumption) simply by not including any record for that feature. All the joined fields will be interpreted as nulls.