A file-deletion call using `java.io.File` returns `false`, and the log just says "could not delete." A teammate wants to know why the delete failed — permission denied, the file was already gone, or something else. Why can't `File` tell you, and what changes with `java.nio.file.Files`?

File.delete() returns a plain boolean, and that boolean collapses every possible reason into the same value: the file didn't exist, a parent directory was read-only, another process had it open — all of them come back as false, with no way to tell which happened without extra checks of your own, and those checks are themselves racy (the file's state can change between the check and the delete). Files.delete(path), the NIO.2 equivalent, either succeeds silently or throws a specific typed exception — NoSuchFileException, DirectoryNotEmptyException, AccessDeniedException — each carrying the path and a real reason from the OS, not a boolean that erased it. Switching from File to Files here doesn't introduce a new failure mode; it makes an existing, previously invisible failure loud and specific, which is exactly what the teammate is asking for.