[ http://issues.apache.org/jira/browse/DERBY-1061?page=comments#action_12369741 ]
David Van Couvering commented on DERBY-1061: -------------------------------------------- In regards to your question of "why not go to SQLException directly?" the value is that when you construct a SqlException with a valid logger (and we should generally strive to use a valid logger), the constructor logs the exception and all sqlca details. You can't accomplish this is you construct java.sql.SQLExceptoin directly. David > SqlException while fetching message results in recursive calls between > SqlException.getSQLException and Sqlca.getJDBCMessage > ---------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1061 > URL: http://issues.apache.org/jira/browse/DERBY-1061 > Project: Derby > Type: Sub-task > Reporter: Anurag Shekhar > Assignee: Anurag Shekhar > Attachments: derby-1061.diff, derby-1061_2.diff, derbyall_report.txt > > stored procedure is used to fetch localised message in net work client > because of issue 1059 the call to the stored prcedures fails resulting in > SqlException. When SqlException.getSQLException, to set > exceptionThrownOnStoredProcInvocation_, is called it again results in a call > to SqlException.getMessage which call Sqlca.getJDBCMessage. > The cycle repeats and finally ends up with StackOverfilowError > fixing 1059 will solve this problem temporarily but some other situaltion may > cause it again. > Isuggest seting SqlException itself to exceptionThrownOnStoredProcInvocation_ > to break this loop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
