stepplerussvenomпропущено...
У меня для вас новости еще хуже - при вашем подходе у нас имеет место быть точно такая же проблема, ибо от момента получения ошибки OS до момент ее обработки с файлом точно так же может произойти все, что угодно.

То есть, вот авторы новой редакции совсем лохи, да?

public static void delete(Path path)
throws IOException

Чорт, даже void, даже не boolean.

"Я знал, я знал" (С)

Идите уже, почитайте нормальные книги, как правильно программы писать.
Учителя, е-мое.Почему же лохи? Просто описанная вами проблема - когда от момента возникновения ошибки до ее обработки что-то может изменить состояние файла - не решаема в рамках JVM, хоть вы boolean возвращайте, хоть код ошибки ОС, хоть бросайте эксепшн.
Поэтому с точки зрения прикладного программиста проблема обработки ошибок работы с файлом принципиально будет решаться одинаково хоть в JVM6, хоть в JVM7.

stepplerussvenomпропущено...
Почему же лохи? Просто описанная вами проблема - когда от момента возникновения ошибки до ее обработки что-то может изменить состояние файла - не решаема в рамках JVM, хоть вы boolean возвращайте, хоть код ошибки ОС, хоть бросайте эксепшн.
Поэтому с точки зрения прикладного программиста проблема обработки ошибок работы с файлом принципиально будет решаться одинаково хоть в JVM6, хоть в JVM7.

Ну, у методов либо есть атомарность, либо нет.
И да, устройство может отвалиться после того, как я открою файл. А в юниксах его могут еще и удалить пока я его читаю. Но в этих случаях я расчитываю получить именно ту ошибку, которая произошла и именно при той операции, которую я делаю.

А не так, что я проверил, что файл есть, открываю его, а его нет. А ошибку уже не обрабатываю. Зачем? Я же уже проверил, что файл есть. Что за ерунда?Речь шла не про предварительные проверки перед совершением операции, а про определение источника ошибки после ее возникновения - 13083383 . То есть в старой редакции (до 7), когда возникает ошибка, мы не знаем, чем она была вызвана. Для этого мы, если нам это требуется, производим определенные проверки - есть ли файл на месте, есть ли у нас права, и т.д.. По итогам этих проверок мы решаем, что делать дальше. В JVM7 мы уже получаем вменяемое описание ошибки.
Так вот, смысл заключается в том, что с точки зрения обработки исключительной ситуации у нас может возникнуть race condition как в первом случае, так и во втором. Когда, например, мы поняли, что папка не удалилась, так как они не пустая, мы начинаем ее очищать, но кто-то другой уже сделал это - то есть мы впустую потратили время. Поэтому с точки зрения простоты использования, редакция JVM7, разумеется, выглядит более привлекательно, спору нет. Но с точки зрения семантики обработки исключений принципиально не меняется абсолютно ничего, ибо ни первый, ни второй подход не дают нам гарантий того, что имеющиеся у нас сведения о произошедшей ошибки не устарели к тому моменту, когда мы приступаем к ее обработке.