In my experience, Pro does throw an error if you're editing an existing feature and try to NULL a non-nullable field. If you're creating a new feature, it fills in the default value. If you didn't specify a default value in your schema, then it uses one of the default defaults that you mentioned above.
As for why you might want to use NULL vs a Default/Sentinel Value:
Let's consider implementing a material field on a Storm Pipe feature in my organization, in two different approaches. The Default Value is what is there for a newly-created feature whose material hasn't been determined, yet. The Filled Test Value is what is there for a different feature whose material has been determined.
| Approach A | Approach B |
- NULL Prohibited
- Default Value: "Unknown"
- Filled Test Value: "Concrete"
| - NULL Permitted
- Default Value: NULL
- Filled Test Value: "Concrete"
|
Now, let's assume I want to run some python code on this field. Maybe I only want to keep the first three letters, now, and capitalize them:
!materialfield![:3].upper()
The above code—if entered in the Field Calculator in Python mode—should take the first three characters, capitalize them all, and throw away everything else.
Let's first look at that filled test value:
| | Approach A | Approach B |
| Original Value | "Concrete" | "Concrete" |
| Expected Results | "CON" | "CON" |
| Actual Results | "CON" | "CON" |
So far, so good. But the way we ran that code, it's also going to run on the features with that default value. Let's see how those look:
| | Approach A | Approach B |
| Original Value | "Unknown" | NULL |
| Expected Results | "UNK" | NULL |
| Actual Results | "UNK" | A Python TypeError stops your code in its tracks |
I'm sure there are plenty of other similar examples. But at its root, you'd enforce NULL if you wanted to ensure that the data type for that column is always the same, whether the cell is populated or not. Because in both SQL and Python (and I think Arcade?) NULL is technically a different data type and will break some functions.
