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
<mailto: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
