Invalid reference in persistent store

Question

Scenario: an object in the persistent store holds an invalid reference
(either an object with the referenced id does not exist or it can't be
instantiated for some other reason). When the object is loaded in
memory, an attempt to navigate the invalid reference does not generate
an exception, but instead returns a null. This doesn't seem correct.
I've attached a simple test case that demonstrates the problem.
Alex Albu
Commerce Technologies, Inc.
21 Corporate Drive
Clifton Park, NY 12065

Answer 1

I might be subjective here, but I don't agree, Abe. I don't think that
checking the return value of each method call is the norm in Java. It
is in C, but Java's exceptions are meant to relieve you from this
burden. After all, inconsistent data really is an exceptional
circumstance. Obviously, the granularity of your try/catch blocks,
won't be at the line level. To me, navigating a reference is very
similar with PersistenceManger.getObjectById(). It won't return a null
if the object isn't present in the data store.
Nulls are many times legal values and substituting them for invalid
references takes away the possibility to distinguish between good and
bad data. Code handling invalid references just like it handles nulls
is most likely going to produce wrong results whose cause is going to be
hard to determine.
We have gone to great lengths to ensure that our object model stays
consistent. For example, if A's bField is required by business rules to
be non-null, then our object model offers no way to construct an A
object with a null bField. So if there ise no circumstance under which
bField's getter would return null, why check? If the model has become
inconsistent, that's a serious issue (at least for us) and it is
critical for the application to signal that right away in a clear
fashion (NPE's don't mean anything to production support).
Anyway, as I said, this is just my opinion and I can see how other users
might find your decision suited for their applications. Offering an
option that allows users to control this behavior seems appropriate.
Abe White wrote:
And I'm not sure this behavior is helpful anyway. If you're
trying to dereference an invalid reference, you'll get a NPE,At least it's possible to check for nulls and avoid NPEs. If we threw
an execption on any attempt to load an invalid reference, it would be
impossible for users to avoid the exception.
Consider the following extremely common case:
* Object A has a field bField with a reference to object B.
* Object B is deleted, but the user does not null object A's bField reference.
* Later, the user finds object A and calls A.getBField () to do some operation
on the related B if it exists.
The vast majority of users just want a null to be returned if no related object
exists. Users almost always check for null when dealing with returned objects
in Java; it doesn't get in the way of their programming. Having the
possibility of any getter method for a relation throw an exception, though --
that would force users to build in a lot of exception handling code that
they wouldn't normally include. It breaks the transparency of JDO.
anyway. I guess the only way you can take advantage of this
feature (?) is to test references for null before accessing
them, which doesn't seem reasonable.As stated above, code like this:
B b = a.getBField ();
if (b != null)
is the norm in Java. Code like this:
B b;
try
b = a.getBField ();
catch (JDOUserException jue)
... what could I possibly do to recover here? ...
is not. Additionally, you would still need to do the null check in most
situations, because bField could simply have been set to null.
You can avoid either situation by keeping your object model consistent. This
feature is for careless users. If they're so careless that they also don't
check for null objects, then yes, they'll get a NPE. But with your solution,
they'd get an exception anyway, just a different kind... and an unavoidable
one at that.
I'm interested, though: how would throwing a JDOUserException immediately
help your code? If you can make a compelling enough case, we could offer
this as an option...