最近在整代码的持续集成,findbugs进行代码的静态检查。其中一个findbugs警告解决了好久,先看示例代码:
private void copyDataBase() {
InputStream myInput = null;
OutputStream myOutput = null;
try {
String inFileName = "";//your local db path
// Open your local db as the input stream
myInput = new FileInputStream(inFileName);
// Path to the just created empty db
String outFileName = ""//the new db file u want to create;
// Open the empty db as the output stream
myOutput = new FileOutputStream(outFileName);
// transfer bytes from the inputfile to the outputfile
byte[] buffer = new byte[1024];
int length;
while ((length = myInput.read(buffer)) > 0) {
myOutput.write(buffer, 0, length);
}
// Close the streams
myOutput.flush();
myOutput.close();
myOutput = null;
myInput.close();
myInput = null;
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if(myInput != null) {
myInput.close();
}
if(myOutput != null) {
myOutput.close();
}
} catch (IOException e) {
e.printStackTrace();
}
myInput = null;
myOutput = null;
}
}
首先来看findbugs的警告:
OBL_UNSATISFIED_OBLIGATION, Priority: Normal
OBL: copyDataBase() may fail to clean up java.io.OutputStream
This method may fail to clean up (close, dispose of) a stream,
database object, or other resource requiring an explicit cleanup
operation.In general, if a method opens a stream or other resource, the method
should use a try/finally block to ensure that the stream or resource
is cleaned up before the method returns.This bug pattern is essentially the same as the **OS_OPEN_STREAM and
ODR_OPEN_DATABASE_RESOURCE** bug patterns, but is based on a different
(and hopefully better) static analysis technique. We are interested is
getting feedback about the usefulness of this bug pattern. To send
feedback, either: •send email to findbugs@cs.umd.edu •file a bug
report: http://findbugs.sourceforge.net/reportingBugs.htmlIn particular, the false-positive suppression heuristics for this bug
pattern have not been extensively tuned, so reports about false
positives are helpful to us.See Weimer and Necula, Finding and Preventing Run-Time Error Handling
Mistakes, for a description of the analysis technique.
这里提示应该用try/finally来确保stream的clean up,但函数里也使用了finally,判断stream是否释放了,为什么还是报这样的警告呢?
然后再尝试在catch中也加入对stream的处理
catch (IOException e) {
e.printStackTrace();
try {
if(myInput != null) {
myInput.close();
}
if(myOutput != null) {
myOutput.close();
}
} catch (IOException e) {
e.printStackTrace();
}
myInput = null;
myOutput = null;
}
然并卵,还是报同样的警告。
最后仔细研究了findbugs的提示“use a try/finally block”,是不是这里不能使用catch了呢?就尝试在函数抛出异常到外部处理了
private void copyDataBase() throws IOException {
InputStream myInput = null;
OutputStream myOutput = null;
try {
String inFileName = "";//your local db path
// Open your local db as the input stream
myInput = new FileInputStream(inFileName);
// Path to the just created empty db
String outFileName = ""//the new db file u want to create;
// Open the empty db as the output stream
myOutput = new FileOutputStream(outFileName);
// transfer bytes from the inputfile to the outputfile
byte[] buffer = new byte[1024];
int length;
while ((length = myInput.read(buffer)) > 0) {
myOutput.write(buffer, 0, length);
}
// Close the streams
myOutput.flush();
myOutput.close();
myOutput = null;
myInput.close();
myInput = null;
} finally {
try {
if(myInput != null) {
myInput.close();
}
if(myOutput != null) {
myOutput.close();
}
} catch (IOException e) {
e.printStackTrace();
}
myInput = null;
myOutput = null;
}
}
重新findbugs检查下,发现不再报警告了。
可能findbugs的检查机制是只能在finally中处理stream的异常吧,所以这里不能出现catch,异常抛出外部处理当然就检查不到了。
但是findbugs这里也提了,这个警告可能也不需要调整修改,可能是错误的建议,可以反馈给findbugs。
In particular, the false-positive suppression heuristics for this bug
pattern have not been extensively tuned, so reports about false
positives are helpful to us.
这里仅分享下此findbugs警告的修改方法,不强制说一定要修改此警告。
转载请声明原文地址:
http://blog.csdn.net/sagittarius1988/article/details/49795795