db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mike matrigali <mikema...@gmail.com>
Subject Re: XmlVTI.next() invocation of printStackTrace()
Date Sun, 28 Jun 2015 18:13:37 GMT
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.derby@gmail.com <mailto:bpendleton.derby@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 - mikemapp1@gmail.com
linkedin: https://www.linkedin.com/in/MikeMatrigali


Mime
View raw message