Invalid reference in persistent store - Weblogic

> memory, an attempt to navigate the invalid reference does not generate
> an exception, but instead returns a null.

This was a conscious decision on our part. Many users constantly leave
behind invalid references, or have legacy data stores that contain
invalid references.

>>memory, an attempt to navigate the invalid reference does not generate
>>an exception, but instead returns a null.
>
>
> This was a conscious decision on our part. Many users constantly leave
> behind invalid references, or have legacy data stores that contain
> invalid references.

But this makes data problems difficult to find, since they will
hide behind NullPointerExceptions. It considerably increases the
time it takes us to troubleshoot data problems. And that can
only be done by a developer familiar with the code instead of a
production support person.

And I'm not sure this behavior is helpful anyway. If you're
trying to dereference an invalid reference, you'll get a NPE,
instead of a JDOException -- why is that better? And if you're
not accessing the object at all, you won't get an exception
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.

> 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 referen=
ce.
* Later, the user finds object A and calls A.getBField () to do some operat=
ion
on the related B *if* it exists.

The vast majority of users just want a null to be returned if no related ob=
ject
exists. Users almost always check for null when dealing with returned obje=
cts
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.
=20
> 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 =3D a.getBField ();
if (b !=3D null)
{
....
}

is the norm in Java. Code like this:

B b;
try
{
b =3D 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. Th=
is
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 solutio=
n,
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...

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 refer=
ence.
> * Later, the user finds object A and calls A.getBField () to do some oper=
ation
> 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 ob=
jects
> 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, thoug=
h --
> 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 =3D a.getBField ();
> if (b !=3D null)
> {
> ....
> }
>
> is the norm in Java. Code like this:
>
> B b;
> try
> {
> b =3D 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 mos=
t
> 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 solut=
ion,
> they'd get an exception anyway, just a different kind... and an unavoidab=
le
> 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...

> 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.

Agreed. Here is the enhancement request:
https://bugzilla.solarmetric.com/show_bug.cgi?id=3D362