I would then propose to make sure that (i hope your font is non-proportional..): field marked as NOT NULL field not marked as NOT NULL get<Type>Value getValue get<Type>Value getValue field unset -1,"" -1 -1,"" null field set to null <previous value> <previous value> -1,"" null field set 123,"123" 123 123,"123" 123
In this scheme I tried to indicated the several possibilities, for setting and getting a field.
I think an unset field should possible return 'null' with getValue() even if it is marked as NOT NULL. Or perhaps it should throw an exception. The method getNodeValue() should also do this, as there is no 'empty node' value.
Returning null for a field that cannot be NULL may be strange, but in the case of a (new) node being editted on, this can happen.
Either we rule that in this situation null can be returned (and document that as such), or we throw an exception.
- What are the 'empty' presentations of NODE and XML fields?
-XML: According to the javadoc getXMLValue could return 'null' (though does not say that that should happen if unfilled). It gives back the Document '[#document: null]'. That might be ok.
I am in favor to return an empty document.
-NODE: I propose that the 'empty' node must be some virtual node with number=-1. I think it might return 'null' now, which would conflict with the practical notion that e.g. get<Type>Value(..).toString() would never give a NullPointerException.
Should either return null or give a 'node not found' exception.
From a programmers perpsective I am in favor of throwing exceptions. However this may, in some specific cases, give issues regarding backward compatibility, so returning null is an acceptable solution.
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Never summon anything bigger than your head."
