Re: Abstract causes server exception
Re: Abstract causes server exception
- Subject: Re: Abstract causes server exception
- From: Ian Joyner <email@hidden>
- Date: Mon, 5 Sep 2005 10:25:45 +1000
On 03/09/2005, at 3:59 AM, Chuck Hill wrote:
On Sep 1, 2005, at 9:26 PM, Ian Joyner wrote:
On 02/09/2005, at 1:35 PM, Chuck Hill wrote:
Hi Ian,
On Sep 1, 2005, at 6:15 PM, Ian Joyner wrote:
Since I found the solution to my own problem, but could not find
it documented in either the Omni list or here, I thought I'd
write it up in case others hit the same several-hour wasting
problem.
I created a new model in my project and most of the entities
were subclasses of a generic entity, so I created in EOModeler
the generic entity with abstract set and subclassed the entity.
When I ran this, I got an exception on the server side:
[2005-09-02 10:20:44 EST] <WorkerThread5> Server exception: null
[2005-09-02 10:20:44 EST] <WorkerThread5>
java.lang.NullPointerException
at
com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecifica
tionEditingContext(EODatabaseChannel.java:770)
at
com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecifica
tionEditingContext(EODatabaseChannel.java:806)
What I found was that subclassing in EOModeler had not reset the
abstract setting (a property that should not be preserved). This
is strange because properties like client-side attribute are not
preserved when subclassing.
I'm pretty sure that preserving the abstract setting is correct
behavior. Losing the client-side attributes is the bug. It
loses other things too at times.
I'd argue for resetting it on the grounds that it leads to this
trap (purely selfish reason). But also, inheritance hierarchies in
WO tend not to be more than one deep. Even if you are not in WO,
OO classes do not inherit the abstract (deferred in Eiffel)
property of a parent.
BTW, Fetching on an abstract entity should not cause an exception.
I do this to fetch all entities in a hierarchy. Were all the
entities in the hierarchy abstract?
That makes sense, yes they were all abstract (because I'd subclassed
them all the same way in EOModeler).
2) Put a run time check at all the places like line 770 so that
at line 770 (or earlier in the call chain) a fetch against an
abstract entity is rejected. That is put much more DBC into WO
(or just rewrite the whole thing in Eiffel!)
DBC is not meant to be in a deployed app so that is not really a
solution. But EOAccess is far too optimistic about "this won't
ever be null". Much better error condition checking and accurate
error diagnosis is certainly needed.
Correct, but I was thinking perhaps how DBC affects how the rest
of the code is written, ie the method containing line 770 might have:
require
not entity.abstract
callers of this method would then write into their code a real
runtime check that they are not passing abstract (because they
have perhaps run the system and been caught by the development-
time requires clause).
OK, I was looking at it from the point of view that the EOModel
could be considered user input and hence needs to be checked each
time, at runtime.
You'll still have the runtime check – the contract in DBC just states
whether checking is done in the caller or the routine, hence that it
doesn't get missed. Like type checking, this ensures run time code is
more efficient (although DBC minimizes the redundant checks, type
checking removes checking code at compile time).
3) Integrate checks into the build process or into Interface
Builder so that you are not allowed to do anything that might
result in a fetch against an abstract entity in the first place
(this is the difficult option).
That would require static Java analysis and probably more than a
fair bit of intelligence. A RuntimeException seems like the more
appropriate solution.
I wasn't thinking of Java analysis, but something like a check in
IB that a display group was not getting its data source from an
abstract entity. In other words better integration between EOM and
IB and Xcode, but that would probably need a fair bit of
reengineering.
I was thinking of the more general case where display groups are
not used and this mistake is made in code. Hmmm, is this a
JavaClient only bug?
Given your excellent tip above that you should be able to fetch on
abstract entities to get all instances of subclasses, this becomes a
very difficult test, perhaps not impossible, but certainly given the
loose integration between IB and WO (which I still think is pretty
clever), maybe too hard.
I think if all these traps for the unwary/newbie that are
documented in these groups made their way into Apple's code so
that the traps did not exist in the first place, WO would be a
much better development environment akin to type checking in
languages.
Yep, just a question where Apple sees value in allocating its
resources. And is _is_ a hardware company. I'm just happy that
WO made it into Xcode and is getting a new EOModeler and WOBuilder.
I agree, it's good that Apple has now got a way forward for WO.
You'd think with all these industry leading development tools that
Apple's focus would become more development centric – that's the
way into the corporate market where you have to have a good
customer/vendor relationship.
You would think so. But the ways of Apple are mysterious and
inscrutable. Sometimes I use other words too. ;-)
Well, I would not blame Apple for this state of the industry, after
all Apple has to compete with the likes of Dell who have jettisoned
all that stuff in order to undercut the market.
I'm not sure Apple is good at promoting hardware either.
I did not say they were good at it, just that this was their
focus. :-)
mmm ;-(
I don't know if you can categorize these kinds of issues as
"bugs", so how does one get this message to Apple? Does anyone
from Apple actually read these groups?
They do, at least on occasion. I don't know that they read each
and every message. But this is not an appropriate or effective
means of reporting bugs, wished for enhancements etc. Those need
to be filed at http://bugreport.apple.com. Only things reported
there will ever get changed.
I have a good list there already, but most have just been 'open'
for months. I don't really want to hold them up fixing real
defects by submitting wishlists. Oh well.
Months? I should be so lucky! Try years. :-(
Well, that's probably another state of the industry thing. Having
worked for another large vendor (it's not hard to work out which
one), they were very responsive to user reports because the users had
paid millions of dollars for their systems, so they did not want to
lose these sales. However, we pay Apple nothing (not even select let
alone premier), but I submit reports to hopefully help Apple gauge
what problems are common and fix it, so they can get big customers
and everyone will benefit. They did assure us at the Tiger preview
meeting in Sydney that they do take all reports seriously. Let's hope
things really move on WO now, and I think your new book should be
very important.
Ian Joyner
Sportstec
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden