> No there is no way a primitive can hold a null value,
Well, *that's* for sure. :-)
> and there's only one
> way a Method.invoke() can return a null. From the documentation on Method:
[quoted text clipped - 6 lines]
> your passed PropertyDescriptor returns a handle to a nonbean property method
> which is of type void.
... or the member is not a primitive type and it's null. Not the case for
that scenario we're investigating.
> That would be very difficult to do, even if it is
> possible. A good design should preclude even the remotest possibility, but I
> can't say based on the code you posted.
Since I use only standard mechanims to get at the PropertyDescriptors I
think we can rule that out.
> One possible source of the "null" might be your
> convertPropertyValueToString(...) method, which is also not given in your
> posting.
It's handled via a special PropertyEditor for primitive type wrappers
(java.lang.Integer and the like) that either converts to a legal string or
throws. So there should be no 'null's returned here either because the
conversion is only triggered for non null values.
> Another more obscure possibility arises because the code just re-throws the
> exception instead of checking it around the invoke method.
Where did you see the re-throw? Exceptions are just thrown and not caught
by this method. But they are caught and rethrown as another exception
type in the invoking method.
> That way you
> leave yourself vulnerable to the handling further down the call stack where
> less is known about what to do.
It's still handled in the same instance, so all is fine.
> I generally find that at least some
> Reflection exceptions are screened out and handled at the method call or
> rethrown as NestableRuntimeExceptions because they're extremely rare or
> impossible (based on the design) and/or because there's nothing to do about
> them in any case.
Yes, that's done even further up the call stack.
> If the null field is part of an object that is already instantiated and on
> the way to the database, then an exception here (e.g. at the invoke()) would
> leave it null and it might be persisted elsewhere.
No, this is the only place that does the persisting. It's a general
mechanism so it would make no sense to have other code that duplicates
this functionality. Apart from that the 'value' is a local variable, so
the value is lost in case of an exception any way.
> An aside: in the collection handling part of the if (Collection...) clause,
> you have an "if (!element != null) clause without an else clause. Is
> ignoring null collection members really what you intend?
Yes.
> In the debugger, you should trap a "null" string at the update() and a null
> value, and see what else you can learn about the circumstances.
Done - to no avail. :-( I'm still suspecting that someone was fiddling
with the database, although I can't prove it. This seems the only way to
me that these NULL's could have shown up in that table.
Thank you very much for your time!
Kind regards
robert