#java #filereader
#java #программа чтения файлов
Вопрос:
Пожалуйста, объясните поведение компилятора в приведенном ниже фрагменте кода. Рассмотрим текстовый файл, содержащий следующий текстовый файл, а соответствующие значения байтов равны 84, 79, 66, 69
for(int i=0;i<4;i ){
byte inByte=(byte) buffInputFile.read();
system.out.println(inByte);
}
Когда я запускаю этот фрагмент, я получаю следующий вывод
84
79
66
69
Но когда я дублирую цикл for и захожу внутрь. buffInputFile.read() сначала показывает мне 84, а при присвоении inByte это 79. и результат, который я получаю, равен
79,66,69,13 (13 — это возврат каретки).
Ответ №1:
Я подозреваю, что у вас есть выражение просмотра отладчиком buffInputFile.read() , которое считывает значение из потока, чтобы отобразить его… но тогда это значение недоступно, когда метод выполняется как часть кода. Вы прочитали этот байт из потока, поэтому следующий вызов read() прочитает следующий байт в точности так, как и предполагалось.
В общем, это очень плохая идея выполнять методы с побочными эффектами в отладчике подобным образом — это вызывает именно такую путаницу. Если вы просто установите точку останова в строке после назначения, вы сможете видеть значения таким образом.
Короче говоря: это вовсе не из-за неправильного поведения компилятора — это способ, которым вы используете отладчик.
Комментарии:
1. Спасибо, Джон… Есть ли какой-либо способ, которым я могу это преодолеть.. Потому что мне нужно отладить и проверить..
2. Спасибо, Джон… Это было очень полезно.. Я предполагаю, что код правильный, а способ, которым я отлаживал, был неправильным….
3. @rozar: Да. Я предполагаю, что вы где-то добавили выражение наблюдения
buffInputFile.read()(неясно, какой отладчик вы используете) — в принципе, не добавляйте выражения наблюдения с побочными эффектами.
Ответ №2:
Это не ошибка, это особенность. read Метод возвращает следующий байт из потока и устанавливает внутренний маркер в следующую позицию.
При проверке buffInputFile.read() с помощью отладчика вы эффективно вызываете этот метод, и отладчик показывает фактическое значение. Но маркер был установлен в следующую позицию и поэтому inByte получит следующее значение из потока.