除了可能在任何方法调用中引发异常（如系统压力过大导致 或由于编程器错误导致 ），.NET 文件系统方法还可能引发以下异常：
- ，所有 异常类型的基类。 当出现操作系统的返回代码不直接映射到任何其他异常类型的错误时将引发此异常。
- 。
- 。
- 。
- 。
- 。
- 。
- 当 .NET Framework 和 .NET Core 2.0 以及先前版本上的路径字符无效时，将引发 。
- 当 .NET Framework 中存在无效冒号时，将引发 。
- 当在受限制的信任中运行的应用程序缺少仅限于 .NET Framework 的所需权限时，将引发 。 （完全信任是 .NET Framework 的默认设置。）
由于文件系统为操作系统资源，.NET Core 和 .NET Framework 中的 I/O 方法将包装对基础操作系统的调用。 当由操作系统执行的代码出现 I/O 错误时，操作系统将对 .NET I/O 方法返回错误信息。 然后，该方法会将错误信息（通常采用错误代码形式）转换为 .NET 异常类型。 大多数情况下，可以通过直接将错误代码转换为其相应异常类型来完成此操作；它不基于方法调用的上下文执行任何特殊的错误映射。
例如，在 Windows 操作系统，返回 （或 0x02）错误代码的方法调用会映射到 ， 错误代码（或 0x03）则映射到 。
但是，操作系统返回特定错误代码的精确条件通常未记录或记录不当。 因此，会出现意外异常。 例如，因为使用的是目录而不是文件，可以预料到向 构造函数提供无效目录路径将引发 。 但是，它也可能引发 。
由于操作系统的这一依赖性，相同异常条件（例如在我们的示例中没有发现错误目录）可能会导致 I/O 方法引发任何一种 I/O 异常。 这意味着，在调用 I/O API 时，代码应准备好处理大多数或者所有这些异常，如下表所示：
作为 命名空间中异常的基类，当任何错误代码未映射到预定义的异常类型时，也将引发 。 这意味着异常可以由任何 I/O 操作引发。
此外，从 .NET Core 2.1 开始，已删除对路径正确性（例如，为了确保路径中不存在无效字符）的验证检查，且运行时会引发从操作系统错误代码（而非从它自己的验证代码）映射的异常。 在这种情况下，最有可能引发的异常是 ，虽然也可能引发任何其他异常类型。
请注意，在异常处理代码中，应始终最后处理 。 否则，因为它是所有其他 IO 异常的基类，将不会评估派生类的 catch 块。
在 情况下，可以从 IOException.HResult 属性获取更多错误信息。 若要将 HResult 值转换为 Win32 错误代码，可以删除 32 位值的前 16 位。 下表列出了可能包装在 中的错误代码。
可以使用 catch 语句中的 子句来处理这些问题，如以下示例所示。
- 在 .NET 中处理和引发异常
- 异常处理（任务并行库）
- 针对异常的最佳做法
- 如何在 catch 块中使用特定异常
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/rfx/60375.html