db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shreyas Kaushik <Shreyas.Kaus...@Sun.COM>
Subject Re: jdbcapi/testRelative intermittent diff
Date Mon, 18 Apr 2005 04:42:28 GMT
Hi Mamta,

Attached is the patch thtat takes care of this. I wanted to change this 
as you said, but missed it, thanks for pointing this out.

~ Shreyas

Mamta Satoor wrote:

>Hi Shreyas,
>
>If the exception in testRelative is expected, then you don't want to
>print it as FAIL - expected exception.
>
>For eg, in the test case below, I expect an error for deleteRow on a
>read only resultset and hence I put it in a try catch block and catch
>the exception and print it as expected exception. If the exception
>that you get in the testRelative is expected, then printing it with
>FAIL message is misleading. Hope this calrifies things.
>
>System.out.println("Request a read only resultset and attempt deleteRow on it");
>stmt = conn.createStatement();//the default is a read only forward
>only resultset
>rs = stmt.executeQuery("select * from t1");
>rs.next();
>try {
>  rs.deleteRow();
>  System.out.println("FAIL!!! deleteRow should have failed on a read
>only resultset");
>}
>catch (SQLException e) {
>  System.out.println("SQL State : " + e.getSQLState());
>  System.out.println("Got expected exception " + e.getMessage());
>}
>
>
>On 4/17/05, Shreyas Kaushik <Shreyas.Kaushik@sun.com> wrote:
>  
>
>>Hi Kathey,
>>
>>I have takne care of your concerns here. Please find the patch attached.
>>If you need anything more let me know.
>>
>>thanks
>>Shreyas
>>
>>Kathey Marsden wrote:
>>
>>    
>>
>>>Shreyas Kaushik wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Hi Kathey,
>>>>
>>>>I ran this test with different profiles, that is on machines having
>>>>different Operating Systems and also
>>>>when the load on the systems were high. I did not notice this test
>>>>failing even once.
>>>>
>>>>The message in the master says Unexpected Exception, actaully a
>>>>SQLExcpetion is being caught and the message
>>>>        
>>>>
>>>>from there displayed. I can change the message if you want, but I
>>>      
>>>
>>>>don't see any other problem.
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>This is the canon that is checked in:
>>>
>>>Test testRelative starting
>>>Value=work1
>>>isFirst=false isLast=false isAfterLast=false
>>>Value=work3
>>>Value=work1
>>>isFirst=false isLast=false isAfterLast=true
>>>FAIL -- unexpected exception
>>>SQLSTATE(24000): SQL Exception: Invalid cursor state - no current row.
>>>SQL Exception: Invalid cursor state - no current row.
>>>
>>>So my big question is, Is  the exception  expected or unexpected?
>>>
>>>If it is expected, I suggest you change the test do something like:
>>>   System.out.println(" EXPECTED EXCEPTION:
>>>SQLSTATE("+se.getSQLState()+"): "+se.getMessage());
>>>    and not print a stack trace.  Looking at the test you would need a
>>>separate try/catch block for the case in which
>>>    the exception is expected.
>>>
>>>If it is indeed unexpected then the test is fine. Derby needs to be
>>>fixed to behave properly and the canon updated accordingly.
>>>
>>>------------------------------------------------------------------------
>>>Why the intermittent diff?
>>>
>>>In the past I have seen cases where we get this type of diff when there
>>>is a  sqle.printStackTrace()
>>>for an expected exception.  The first line of the stack trace ends up in
>>>the .out file.
>>>
>>>The timing issue,  especially in sane builds is that printStackTrace()
>>>will print to System.err.  The test harness redirects both System.err
>>>and System.out to the same file, so from time to time, the output of
>>>these two statements might show up in reverse order.
>>>  System.out.println("SQLSTATE("+se.getSQLState()+"): "+se);
>>>   se.printStackTrace();
>>>
>>>------------------------------------------------------------------------------------------
>>>To avoid the timing problem and confusion:
>>>
>>>   1) Always have your test print whether the exception is expected or
>>>unexpected.
>>>   2) Never print a stack trace for  an expected exception.
>>>   3) Always print a stack trace for an unexpected exception.
>>>
>>>And one supplemental tip:
>>>
>>>   4) For expected exceptions print  se.getMessage() instead of  just
>>>se. Then it will work for Network Server too.
>>>
>>>Hope that clarifies things.
>>>
>>>Kathey
>>>
>>>
>>>
>>>
>>>      
>>>
>>Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
>>===================================================================
>>--- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
 (revision 161449)
>>+++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
 (working copy)
>>@@ -80,7 +80,6 @@
>>
>>               } catch(SQLException sqle) {
>>                  dumpSQLExceptions(sqle);
>>-                  sqle.printStackTrace();
>>               } catch(Throwable e) {
>>                  System.out.println("FAIL -- unexpected exception: "+e);
>>                   e.printStackTrace();
>>@@ -89,10 +88,10 @@
>>      }
>>
>>      static private void dumpSQLExceptions (SQLException se) {
>>-                System.out.println("FAIL -- unexpected exception");
>>+                System.out.println("FAIL -- expected exception");
>>                while (se != null) {
>>                        System.out.println("SQLSTATE("+se.getSQLState()+"): "+se);
>>                        se = se.getNextException();
>>                }
>>        }
>>-}
>>\ No newline at end of file
>>+}
>>Index: java/testing/org/apache/derbyTesting/functionTests/master/testRelative.out
>>===================================================================
>>--- java/testing/org/apache/derbyTesting/functionTests/master/testRelative.out  (revision
161449)
>>+++ java/testing/org/apache/derbyTesting/functionTests/master/testRelative.out  (working
copy)
>>@@ -4,6 +4,5 @@
>>Value=work3
>>Value=work1
>>isFirst=false isLast=false isAfterLast=true
>>-FAIL -- unexpected exception
>>+FAIL -- expected exception
>>SQLSTATE(24000): SQL Exception: Invalid cursor state - no current row.
>>-SQL Exception: Invalid cursor state - no current row.
>>
>>
>>
>>    
>>

Mime
View raw message