Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
package java.nio.file;
public final class Files {
/**
* Convert a Closeable to a Runnable by converting checked IOException
* to UncheckedIOException
*/
private static Runnable asUncheckedRunnable(Closeable c) {
return () -> {
try {
c.close();
} catch (IOException e) {
throw new UncheckedIOException(e);
}
};
}
}
стандартные потрошки джавы это какая-то запредельная протомразь, нарушающая собственные законы физики и запрещающая делать это другим
А в чём суть? Конвертируем чекед в анчекед, чтобы вызывающий код не обязательно было оборачивать в try...catch, а поскольку чекед мы должны где-то обработать, прячем этот try...catch в кишки класса?
Там эта конвертация нужна для закрытия стримов, у коих close-хэндлеры обязаны иметь тип Runnable. Автор видимо поленился в исходниках посмотреть, где этот метод используется, и сразу побежал кукарекать на гк
в глотании IOException, который изначально предназначен для обработки.
если закрывающий хендлер работает с ИО, но ему запрещено кидать ИОЭкцепцен - это хуевый апи.
тем более что можно в любой другой эксепшен напихать suppressed, если мы волнуемся за то, что закрыть его надо потому что операция провалилась из-за какого-то другого исключения
Где ты увидел глотание IOException? Оно заворачивается в unchecked exception и летит выше точно так же как оригинальный checked, и точно так же может быть обработано. Данный метод конечно является костылём, но он служит вполне конкретной цели -- чтобы обойти ограничение на checked exceptions в сигнатуре метода close. `public void close() throws IOException;`
Такой метод нельзя использовать в Runnable напрямую, нужно оборачивать в try/catch, чтобы в onClose был метод без всяких throws IOException в сигнатуре. Иначе ошибка компиляции.
Согласен, что это тянется из ванильной джавы и ее ебанутого дизайна исключений, но конкретно этот код не говно
К слову, в другом месте джава этот IOError из close() таки молча жрала. И из-за этого при нехватке места на диске можно успешно получить запоротый файл. Я где-то эту багу постил тут.
А всё из-за того, что нарушили SRP и смешали flush и close в одной функции.
Типа программистам удобно что последний кусок автоматически флашится при закрытии, а не проёбывается. А на самом деле кучу гемора создали. Легче было бы flush() звать в успешной ветке, чем думать как же обработать ошибку от close().
Согласен.
Закрытие файла должно быть просто уничтожением структуры в памяти ядра и удалением записи в таблице дескрипторов процесса, и никогда не должно падать
Это и есть глотание. Был в сигнатуре, да сплыл. Теперь это рантайм эксепшен, который не надо обрабатывать, потому что это "неправильно написанная программа", а не "диск поебался"
чтобы вызывающий код не обязан был пирдолица с твоим чекд исключением
Чекнд исключения отличная идея была, к сожалению никто в мире не понял, как ей пользоваться
там даже в том же Files проверка существования узлов в файловой системе как-то так делается
Зачем? Зачем? Чтобы закидывать закрывашку в тредпул?
если закрывающий хендлер работает с ИО, но ему запрещено кидать ИОЭкцепцен - это хуевый апи.
тем более что можно в любой другой эксепшен напихать suppressed, если мы волнуемся за то, что закрыть его надо потому что операция провалилась из-за какого-то другого исключения
Согласен, что это тянется из ванильной джавы и ее ебанутого дизайна исключений, но конкретно этот код не говно
А всё из-за того, что нарушили SRP и смешали flush и close в одной функции.
Типа программистам удобно что последний кусок автоматически флашится при закрытии, а не проёбывается. А на самом деле кучу гемора создали. Легче было бы flush() звать в успешной ветке, чем думать как же обработать ошибку от close().
Закрытие файла должно быть просто уничтожением структуры в памяти ядра и удалением записи в таблице дескрипторов процесса, и никогда не должно падать
Пусть бы все делали флаш вручную
З.Ы. С другой стороны, я и сам могу позвать flush(), а потом забить на ошибку close(). Но гарантий насчёт этого нету.
Но вообще тут соснули конечно еще и чекды: тебя заставляют давить то, что никогда не может случиться, и давка эта вербозна
https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/IOUtils.html#closeQuietly-java.io.Closeable...-
И это реальный залёт на разрушение данных.