openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Easier strategy to debug "Fail to convert to internal representation"
Date Wed, 23 Dec 2009 22:30:06 GMT

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.


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
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message