Re: Abstract causes server exception
Re: Abstract causes server exception
- Subject: Re: Abstract causes server exception
- From: Chuck Hill <email@hidden>
- Date: Fri, 2 Sep 2005 10:59:23 -0700
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._selectWithFetchSpecificat
ionEditingContext(EODatabaseChannel.java:770)
at
com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecificat
ionEditingContext(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?
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.
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?
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. ;-)
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. :-)
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. :-(
Chuck
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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