我需要设计一个将OutputStream作为参数的API方法。
关闭API方法中的流或让调用者关闭它是一个好习惯吗?
test(OutputStream os) {
os.close() //???
}
答案 0 :(得分:6)
我认为它应该是对称的。
如果您不打开该流(可能是您的情况),您通常也不应该关闭它。
答案 1 :(得分:3)
除非API的目的是“完成流”,否则应该让调用者关闭。他首先拥有它,他对此负责,他可能会决定将一些内容写入您的API最初未设想的流中。保持您的功能分离;它更具组合性。
答案 2 :(得分:3)
让用户关闭它。当您在参数中使用OutputStream时,我们可以认为用户已经创建并打开它。因此,如果你关闭你的方法,那将是不好的。如果您只是将新的OutputStream作为参数并在方法中打开它,则无需将其作为参数,您也可以在方法中将其关闭。
答案 3 :(得分:0)
不同的用例需要不同的模式,例如,取决于调用者在调用完成后是否需要读取或写入流。
关键的API设计规则是API 指定是关闭流的调用方还是被调用方法的责任。
话虽如此,如果打开流的代码也负责关闭它,通常会更简单,更安全。
考虑methodA
应该打开流并将其传递给methodB
的情况,但是在打开的流和methodB
进入try
之间抛出异常} / finally
声明,最终负责关闭它。您需要对其进行编码,以确保流不会泄漏:
public void methodA() throws IOException {
InputStream myStream = new FileInputStream(...);
try {
// do stuff with stream
methodB(myStream);
} finally {
myStream.close();
}
}
/**
* @param myStream this method is responsible for closing myStream.
*/
public void methodB(InputStream myStream) throws IOException {
try {
// do more stuff with myStream
} finally {
myStream.close();
}
}
由于methodA
或methodB
中引发的异常(或错误!),这不会泄漏开放流。 (它适用于标准流类型,因为Closable
API指定close
在已关闭的流上调用时无效。)