Make DataObjectAccessException extend CastorException rather than RuntimeException

[werner]
re DataObjectAccessException: this class extends RuntimeException, and is solely
thrown in FieldMolder.setValue(). As it is a derived from RunTimeException,
callers of FieldMolder.setValue() do not have to catch this particular
exception. Changing this class to extend CastorException seems to be quite rsiky
to me .. as we are steadily approaching the 0.9.6 release.

Instead, I'd rather replace the

public DataObjectAccessException( String message, Throwable except )

with public DataObjectAccessException( String message, Throwable except )

for the time being, until we agree on a better approach.

[gregory]
Er; assuming that the object getting values set on it may well be locked, or at
the very least in a transaction, I find it difficult to believe that we don't
want to catch and handle this.

[werner]
> Er; assuming that the object getting values set on it may well be
> locked, or at the very least in a transaction, I find it difficult
> to believe that we don't want to catch and handle this.
Gregory, I thinkyou are 100% right, but chnaging all occurences where
FieldMolder.setValue() is called does not look like an option to me at this
point of time. Unless you feel like pushing the 0.9.6 release well after New
Year. Look, it's been broken apparently, but we are not making it worse .. .

[gregory]
OK, open a separate bug and later it; we'll do the API change post-release.

Gregory, how do you feel about providing me with a patch for this issue? Or actually take ownership of this completely. You've got about two weeks to commit this for this to make it into the 0.9.7 release.

Would really like to see a checkin on transaction work first.
But happy to pick this up and do so.

Picking this up again. Gregory, can you provide me with a JUnit test case that causes one of these catch() clauses (that throw a DataaObjectAccessException) to be invoked ?

I think I just managed to come across a situation myself where I found myself suffering from an underlying NullPointerException, which of course wasn't displayed in any way. In other words, I highly favo(u)r changing this as discussed above.

Just came to realize that, if I changed this clas to extend CastorException (or PersistenceException) rather than RuntimeException, this causes a lof of methods in FieldMolder, ClassMolder and ClassMolderHelper to have this exception added as a throws clause. In the end, this change will ripple through RelationCollection and various methods therein. Now, as I cannot change the signature of methods like add(), I would have to convert this (checked) exception to an unchecked exception again .. .

As a result of above finding, I'd suggest to stay with DataObjectAccessException extending RuntimeException, btu at least improve the quality by calling super(String, Throwable) within the DataObjectAccessException(String, Exception) constructor. This will at least improve the quality of the stack trace being produced.

Any views ?

As discussed.

Forgot to mention that above patch introduces yet another dependency on Java 1.4

Commit your patch as is. Don't worry about JDK 1.4 dependency. Close issue as won't fix as we didn't want (are not able to) resolve the original intention of the issue.

Won't fix as discussed above. I have, though, committed a patch that enables exception chaning.