正确处理文件流和二进制流以及处理文件流

mow*_*ker 3 c# error-handling program-flow

实际上,我尝试了对代码进行防错并最终使其看起来非常混乱.

我有一个功能设置来读取某种类型的文件.我希望函数在出现问题时返回false,如果一切正常则返回true.我无法弄清楚如何构建一切.

我有一个尝试打开文件流的初始try-catch块.在那之后,我在读取过程中进行了一些其他检查,例如文件大小和某些偏移处的值.我设置的方式是使用if else语句.如:

if(condition){

}
else{
    MessageBox.Show("There was an error");
    br.Dispose();
    fs.Dispose();
    return false;
}
Run Code Online (Sandbox Code Playgroud)

... br是二进制阅读器,fs是文件流.像这样有很多块,这么多次写同样的东西似乎是不好的做法.首先想到的是将整个事物包装在try-catch语句中并抛出异常而不是使用if else块.我记得在阅读try-catch语句时,拥有它们是好事,但不要用它们包装所有内容.说实话,我仍然不完全理解为什么在try catch语句中包装所有内容都是不好的做法,因为它们只有在出现错误时才会生效,在这种情况下程序正在向南移动...

此外,我是否必须关闭二进制阅读器和文件流,或者关闭一个关闭另一个?有没有办法使用它们而不必处理它们?

Col*_*inE 5

如何使用using关键字?这包含了你IDisposable在try - finally块中的使用;

bool success = true;

using(var fs = new FileStream(fileName, FileMode.Create)))
using(var br = new BinaryReader(fs))
{
  // do something
  success = result;
}

return success;
Run Code Online (Sandbox Code Playgroud)

嵌套的使用块将确保文件流和二进制阅读器始终正确关闭和处理.

您可以阅读有关在MSDN中使用的更多信息.它使用了IDisposable一点点整洁,无需明确的激活处理.

关于你的陈述:

我记得在阅读try-catch语句时,拥有它们是好事,但不要用它们包装所有内容.

我总是使用简单的规则,如果我无法处理并从特定代码块中的异常中恢复,请不要尝试捕获它.允许异常将堆栈'冒泡'到一个更有意义的方法来捕获它.使用这种方法,您会发现您不需要添加许多try-catch块,您将倾向于在与服务集成时使用它们(例如文件系统,网络等......)但您的业务逻辑几乎总是如此没有异常处理机制.