[jira] Created: (OPENJPA-1450) Enhance SQLException thrown from "JDBCStoreManager.load()" to show entity and field info

["David M. Karr (JIRA)" <ji...@apache.org>]

Enhance SQLException thrown from "JDBCStoreManager.load()" to show entity and field info
----------------------------------------------------------------------------------------

                 Key: OPENJPA-1450
                 URL: https://issues.apache.org/jira/browse/OPENJPA-1450
             Project: OpenJPA
          Issue Type: Improvement
          Components: jdbc
    Affects Versions: 1.2.1
            Reporter: David M. Karr
            Priority: Minor


If I define my mapped instance variable to be of a type incompatible with how its stored in the database, I get a "SQLException: Fail to convert to internal representation" error. The error in the log says nothing about what entity and field this is in reference to. This is ok if I test very often, so it's likely that the last entity and/or field I added is the one with the problem, but if the realized relationships in my actual database data won't let me map an instance of that row until I manage to follow a path that loads an instance of that entity, then when I finally get the exception I'll have no clue what entity and field it is referring to.

This is what happened to me.  In order to find the problem, I had to use my debugger skills.  I walked up the call stack until the point where the exception was first caught.  I found that in "JDBCStoreManager.load()". 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.

I wouldn't have had to follow this complicated debugging strategy if the catch clause in this method:

        } catch (SQLException se) {
            throw SQLExceptions.getStore(se, _dict);
        }

incorporated some information about the "ClassMapping" object this method was processing when the exception occurred. This object holds the entity class and other information.

I'm sure there are numerous other places where exception info could be enhanced with useful information. This is only place.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-1450) Enhance SQLException thrown from "JDBCStoreManager.load()" to show entity and field info

["Xiaoqin Feng (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OPENJPA-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794875#action_12794875 ] 

Xiaoqin Feng commented on OPENJPA-1450:
---------------------------------------

I am on vacation from 12/20/2009  to 12/26/2009.

If you have any question on deployment and JEE bugs, please contact Saurabh Arora or my manager Maruthi Nuthikattu.

For emergency, contact me at 925-209-5517.


> Enhance SQLException thrown from "JDBCStoreManager.load()" to show entity and field info
> ----------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1450
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1450
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: jdbc
>    Affects Versions: 1.2.1
>            Reporter: David M. Karr
>            Priority: Minor
>
> If I define my mapped instance variable to be of a type incompatible with how its stored in the database, I get a "SQLException: Fail to convert to internal representation" error. The error in the log says nothing about what entity and field this is in reference to. This is ok if I test very often, so it's likely that the last entity and/or field I added is the one with the problem, but if the realized relationships in my actual database data won't let me map an instance of that row until I manage to follow a path that loads an instance of that entity, then when I finally get the exception I'll have no clue what entity and field it is referring to.
> This is what happened to me.  In order to find the problem, I had to use my debugger skills.  I walked up the call stack until the point where the exception was first caught.  I found that in "JDBCStoreManager.load()". 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.
> I wouldn't have had to follow this complicated debugging strategy if the catch clause in this method:
>         } catch (SQLException se) {
>             throw SQLExceptions.getStore(se, _dict);
>         }
> incorporated some information about the "ClassMapping" object this method was processing when the exception occurred. This object holds the entity class and other information.
> I'm sure there are numerous other places where exception info could be enhanced with useful information. This is only place.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.