+83
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
// java.io.FilterOutputStream
public void close() throws IOException {
try {
flush();
} catch (IOException ignored) {
}
out.close();
}
// тестовый код
try (OutputStream os = new BufferedOutputStream(new FileOutputStream("/tmp/little_virtual_fs/1.txt"))) {
byte[] buf = new byte[2028544];
os.write(buf, 0, 2028544); // максимальный размер файла, который влезает на нашу фс
os.write(buf, 0, 5); // и еще немножко
//os.flush();
}
А сейчас, на арене нашего цирка - очередная жабопроблема!
Как думаете, каков результат выполнения тестовой программы?
Запишет 2028549 байт? Хрен там, места маловато.
Выдаст IOException на write()? Хрен там, буферизация.
Выдаст IOException на close()? Хрен там, его сожрала реализация FilterOutputStream.
Результат: файл не дописался, исключения нет.
Решение: всегда дергать flush() перед close() самому или не юзать буферизованный поток.
Запостил: 
bormand,
21 Декабря 2013
Follow us!
должно работать, наверное, но могу и ошибаться. а то что не выдает IOException это конечно попа.
flush() прямо перед close() или автозакрытием все равно обязателен, иначе BufferedOutputStream.close() сделает его сам, и сожрет исключение.
но до уровня виндов жабе еще далековато.
да такая же обратная совместимость со старыми граблями
Охблядь. Я думал о чем угодно, но не об этом. Я думал питон с его возвратом пустой строки вместо исключения при чтения из потока - унаследованный кал, но и жавку не обошла хуйня сия.
В жавке мне нравилось, что она не тупо копивала апи какой-то оси, соответственно не знакомые с этой осью чувствуют себя объебками.
Resolution: Won't Fix
Жаваёбы дважды соснули.
одна из заповедей жабокодера
кстати, флашить нужно еще и всякие там EntityManager'ы
А почему размер такой магический?