Hi Bryan,

I agree with Mike. That must be a bit of debug scaffolding which I didn't take down. Nuke it!

Thanks,
-Rick

On 6/28/15 11:13 AM, mike matrigali wrote:
It has the feel of something left over while debugging and getting a problem in the try loop. Having the stack is nice in that case but putting it unconditionally into
System.out seems wrong.

did you look at svn history to see if it has always been there or not? I think svn blame
does the trick.

As Kristian points out if you can get t into the exception then calling code could print the exception if it wanted to. The following SQLException constructors might be better, but
might cause same noise depending on what the callers do:
|*SQLException <http://docs.oracle.com/javase/7/docs/api/java/sql/SQLException.html#SQLException%28java.lang.String,%20java.lang.Throwable%29>*(String <http://docs.oracle.com/javase/7/docs/api/java/lang/String.html> reason, Throwable <http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html> cause)|
Constructs a |SQLException| object with a given |reason| and |cause|.
|*SQLException <http://docs.oracle.com/javase/7/docs/api/java/sql/SQLException.html#SQLException%28java.lang.Throwable%29>*(Throwable <http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html> cause)|
Constructs a |SQLException| object with a given |cause|.

On 6/28/2015 3:57 AM, Kristian Waagan wrote:

Hi Bryan,

Firing from the hip, I'd say you can remove it.
Can you set t as cause for the SQLException instead, or will that cause the same amount of "noise"?

I also don't know why Throwable is required, say instead of Exception.

--
Kristian


22.48 Lør 27. Jun 2015 skrev Bryan Pendleton <bpendleton.de...@gmail.com>:


    This method in XmlVTI is causing me a bit of a problem:

         public  boolean next() throws SQLException
         {
             try {
                 if ( _rowIdx < 0 ) { readRows(); }

                 if ( ++_rowIdx < _rowCount )
                 {
                     parseRow( _rowIdx );
                     return true;
                 }
                 else { return false; }
             } catch (Throwable t)
             {
                 t.printStackTrace( System.out );
                 throw new SQLException( t.getMessage() );
             }
         }

    Is there a compelling reason why that call to printStackTrace
    needs to be there?

    I am exercising this code in a regression test, and provoking
    an exception in it, and the unconditional printStackTrace
    makes the test results rather ugly...

    What would be the downside if I removed that printStackTrace() call?

    thanks,

    bryan



--
email:    Mike Matrigali -mikema...@gmail.com
linkedin:https://www.linkedin.com/in/MikeMatrigali

Reply via email to