Andrus wrote:
> I guess having an internal assertion framework is indeed better than just
> keeping endless if..else checks for errors (Please note that having said
Couldn't agree more! Less to type, more flexible in use, easier to change
later.
JDK 1.4 assert() came to mind, but that's probably not good enough and
we'd reintroduce a 1.4 dependency.
> that I am still holding to my earlier opinion that using it for every set*
> method is evil).
I'm afraid I did not formulate my suggestion too well - I didn't want to
add if-then checks to each and every set* method that crosses my way. The
thought came when I was cleaning up some other classes (unrelated to
Cayenne) and found that many set*, as well as some get* - methods were
public for no good reason (they didn't make sense publicly) and actually
allowed a user to break the class, so I started to make them private
wherever possible, protected or public only where necessary. I have done
that to many of my packages now, and while the impact on calling code was
almost zero, the net result is that user code cannot break these classes
anymore.
Remeber that one huge problem with Javas collection classes is that they
can contain null values. While this might look useful in obscure cases,
having an explicit NullObject is usually the preferrable, less problematic
way and also actually what's happening internally when you insert a null
into e.g. a Map. Unfortunately you don't get a typed Collection.NullObject
out again, but stumble over an NPE in a completely different place.
I don't know any good solution to this either, especially for cases where
nulls are allowed and needed (like in Modeler, as you said); it's a
difficult choice to make. Still, most of the time NPE avoidance (by e.g.
gracefully doing nothing after a check) is IMHO preferrable to crashing or
exception throwing.
I also realize this is very much a matter of style & taste, which can
hardly be argued about..especially in light of Cayenne being so good
already, considering it's not even 1.0 yet. :-)
> But we still need to solve a bigger problem - creating specific,
> informative exceptions (or assertions). They should provide as much context
> information as possible:
>
> "XYZ failed due to unmapped ObjAttribute (EntityABC.attr), parent DbEntity:
> (DbEntityABC)" or
> (..)
> And they should be easy to build - no string concatenation on the spot like
> we are doing now. Preferably message strings should be externalized using
> parameters and should be internationalizable.
IIRC Project WONDER has something like that for localized validation
messages (which is a total mess with EOF and has always been). Maybe
someone who is familiar with it (hint ;) could look into extending JAssert
with this? Even without localization just gradually starting to use
something like JAssert in places that we _know_ cannot be
null/wrong/whatever will most likely improve things. I know I'd like to
see something like this.
regards
Holger
This archive was generated by hypermail 2.0.0 : Sat Dec 07 2002 - 18:26:59 EST