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
