Hi,
Just speaking for myself, it's good practice to capture all the "user
domain" information possible in exceptions, logs, and traces.
So it's fair to ask that unhelpful exceptions be "dressed"
appropriately (to help users figure out what they've done wrong or to
identify exactly where the implementation went wrong) by trying to add
some context to the exceptions.
Craig
On Dec 23, 2009, at 2:22 PM, KARR, DAVID (ATTCINW) wrote:
So, I have this big orm.xml that I've been expanding on for the last
couple of weeks. I've tested most of the relationships, but I'm sure
I've missed some.
I had connected a couple more relationships and ran a test, and I got
"SQLException: Fail to convert to internal representation". This
likely
means that the data type I specified for a field doesn't match its
representation. So, I checked the last entities I worked on. I
didn't
see any problems there. I concluded adding the new relationships must
have caused a row of some entity to appear that I haven't worked on
for
a while, but which has this illegal mapping.
Unfortunately, this error and the previous debug output doesn't give
me
any information about which entity and field is in error, so I had to
dig deeper.
In Eclipse I started to walk up the stack to see if I could find a
place
that might possibly give me a clue about where I was. So, I noticed
in
"JDBCStoreManager.load()" that this is the first place where an
exception was caught (numerous stack entries below that were just
processing the exception). I set a breakpoint in here right after it
obtained the "ClassMapping" object, which has the entity class in it.
By watching the printout of the ClassMapping object and noting whether
continuing hit the exception, I finally found the entity that had the
problem. Once I found that, I inspected the fields and found the
problem.
Before I make a suggestion, is there some other information I could
have
looked at to give me a clue about which entity was having the problem?
It seems to me that this "catch" clause in that method (shown below)
is
missing the opportunity to provide a little more useful information.
The resulting SQLException doesn't tell me anything. Is it reasonable
to enhance this to provide more information?
} catch (SQLException se) {
throw SQLExceptions.getStore(se, _dict);
}
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[email protected]
P.S. A good JDO? O, Gasp!
