FileSystemException 磁盘错误码定位方法

处理文件系统异常时，许多开发者倾向于获取底层操作系统错误码，例如 Linux 的 errno 或 Windows 的 GetLastError()。这种追求“精准”的思路可以理解，但在 Java NIO.2 的框架下，可能并非最佳选择。FileSystemException 的设计哲学是提供跨平台的、语义化的错误信息，而非传递不稳定的底层数字代码。有效的精准诊断，应依赖于异常本身提供的两个核心方法：e.getReason() 和 e.getFile()。

为何应避免使用 errno 或 GetLastError？

Java NIO.2 遵循跨平台抽象的设计原则，JVM 已将底层系统错误映射为可读的字符串描述并封装在 FileSystemException 中。强行解析 errno（例如将“Permission denied”对应为数字 13）既无必要也容易出错：不同系统对同一语义操作返回的 errno 可能不同，且 JVM 不保证传递原始值。真正稳定可靠的，是异常实例自带的语义化信息。

getReason()：可靠的错误描述替代方案

e.getReason() 返回操作系统原生的错误描述短语，它比 getMessage() 更纯净、更一致：

• Linux/macOS 常见值：“Permission denied”、“No such file or directory”、“Directory not empty”、“Device or resource busy”
• Windows 常见值：“Access is denied”、“The process cannot access the file because it is being used by another process”、“The directory is not empty”
• 该字段内容不受 JVM 拼接干扰，也不包含路径或其他上下文，适合进行精确的字符串匹配

getFile()：精确定位问题路径

e.getFile() 返回的是触发异常时操作系统实际访问的绝对路径（而非传入的相对路径或符号链接本身）。此路径可用于：

• 在日志中直接记录，方便运维人员在对应机器上手动验证（例如执行 ls -ld /path/to/dir 或 icacls "C:\path\to\file"）
• 自动调用 Files.exists()、Files.isWritable() 等方法复现文件状态
• 区分“目标路径不存在”与“父目录不可写”——例如当 Files.createDirectory(path) 失败时，e.getFile() 通常指向父目录而非欲创建的子目录

应避免的不确定做法

以下方式看似深入，实则可能引入不确定性：

• 试图从 e.getMessage() 中使用正则表达式提取数字（如匹配 \d+）——该字符串格式不稳定，Windows 和 Linux 差异较大，且可能包含行号、时间戳等干扰信息
• 仅用 instanceof FileSystemException 做粗粒度判断后不再解析具体原因——同一异常类型涵盖十多种场景，权限拒绝和文件被占用必须区别处理
• 依赖 SecurityManager 或 AccessController 检查权限——它们反映的是 Java 安全策略，而非实际操作系统文件权限，常出现“策略允许但操作系统拒绝”的误判情况