如何在 Java 中通过 NotDirectoryException 校验传入的文件路径变量是否符合目录操作预期

如何在 Ja va 中通过 NotDirectoryException 校验传入的文件路径变量是否符合目录操作预期

在 Ja va NIO 的世界里，NotDirectoryException 是一个挺有意思的异常。它会在你试图对一个非目录路径执行目录专属操作时跳出来，比如调用 Files.list()、Files.walk() 或者 Files.createDirectory()。但这里有个关键点需要厘清：它本身并非一个校验工具，而更像是一个“事后诸葛亮”——操作已经失败了，它才来告诉你原因。因此，正确的思路不是等着捕获它来做校验，而是应该主动出击，提前判断路径是否为一个有效的目录，从而从根本上避免异常的发生。

用 Files.isDirectory() 主动判断目录有效性

最直接、也最推荐的做法是什么？就是在动手操作之前，先确认一下路径的“身份”。

• 调用 Files.isDirectory(path) 这个方法。如果它返回 true，那就意味着该路径不仅存在、可访问，而且确实是一个目录（而不是文件，或者指向文件的符号链接）。
• 它的好处在于，内部已经帮你处理了路径不存在、权限不足、非目录等各种边缘情况，直接返回 false 来表明不符合预期，整个过程静默而高效，不会抛出异常。
• 来看一个典型的用法示例：

Path dir = Paths.get("/tmp/data");
if (Files.isDirectory(dir)) {
  try {
    Files.list(dir).forEach(System.out::println);
  } catch (IOException e) { /* 处理真正的 I/O 错误 */ }
} else {
  throw new IllegalArgumentException("路径不是有效目录: " + dir);
}

结合 Files.exists() 和 Files.isReadable() 做更严谨的预检

当然，有时候仅仅确认是目录还不够。如果对代码的健壮性要求更高，比如需要确保后续的遍历操作万无一失，那么组合判断往往是更稳妥的选择。

• 先用 Files.exists(path) 确保路径确实存在（注意，默认不追踪符号链接）。
• 再用 Files.isDirectory(path) 确认它的目录属性。
• 最后，别忘了加上 Files.isReadable(path)，这能保证当前进程拥有读取权限，这对于 list()、walk() 这类操作来说是必需的。
• 只有当这三项检查全部通过，返回 true，才可以放心地进行后续的目录遍历操作。

避免依赖 NotDirectoryException 做流程控制

你可能会想，那我用 try-catch 把操作包起来，捕获 NotDirectoryException 不也行吗？理论上可行，但这在实践中被视为一种反模式，原因有几个：

立即学习“Ja va免费学习笔记（深入）”；

• 首先，异常机制本身是有开销的，用它来处理常规的逻辑分支，效率上并不划算。
• 其次，这掩盖了代码的真实意图。你真正需要表达的逻辑是“这个路径能不能当目录用”，而不是“先试试，不行再报错处理”。
• 再者，这样做可能会混淆其他 I/O 异常，比如 SecurityException 或 AccessDeniedException，让错误处理变得复杂而不精准。
• 最后，从代码可读性和设计习惯上看，它违背了“快速失败”和“明确断言”的原则，让代码显得不够清晰。

注意符号链接的默认行为

还有一个细节值得留意：Files.isDirectory(path) 方法在默认情况下是不跟随符号链接的。也就是说，如果 path 是一个指向文件的软链接，它会返回 false；如果指向目录，则返回 true。如果你的应用场景需要对符号链接采取不同的处理策略，可以通过传入 LinkOption.NOFOLLOW_LINKS（这是默认行为）或 LinkOption.FOLLOW_LINKS 来显式指定。