Class IOException
Note that the detail message associated with cause is not automatically incorporated into this exception’s detail message.
IOException
Report a bug or suggest an enhancement
For further API reference and developer documentation see the Java SE Documentation, which contains more detailed, developer-targeted descriptions with conceptual overviews, definitions of terms, workarounds, and working code examples. Other versions.
Java is a trademark or registered trademark of Oracle and/or its affiliates in the US and other countries.
Copyright © 1993, 2023, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.
Class IOException
Note that the detail message associated with cause is not automatically incorporated into this exception’s detail message.
IOException
Report a bug or suggest an enhancement
For further API reference and developer documentation see the Java SE Documentation, which contains more detailed, developer-targeted descriptions with conceptual overviews, definitions of terms, workarounds, and working code examples. Other versions.
Java is a trademark or registered trademark of Oracle and/or its affiliates in the US and other countries.
Copyright © 1993, 2023, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.
Исключения в Java: перехват и обработка
Для работы с исключениями в Java существуют специальные блоки кода: try , catch и finally . Код, в котором программист ожидает возникновения исключений, помещается в блок try . Это не значит, что исключение в этом месте обязательно произойдет. Это значит, что оно может там произойти, и программист в курсе этого. Тип ошибки, который ты ожидаешь получить, помещается в блок catch (“перехват”). Сюда же помещается весь код, который нужно выполнить, если исключение произойдет. Вот пример: Вывод: Мы поместили наш код в два блока. В первом блоке мы ожидаем, что может произойти ошибка “Файл не найден”. Это блок try . Во втором — указываем программе что делать, если произошла ошибка. Причем ошибка конкретного вида — FileNotFoundException . Если мы передадим в скобки блока catch другой класс исключения, оно не будет перехвачено. Вывод: Код в блоке catch не отработал, потому что мы “настроили” этот блок на перехват ArithmeticException , а код в блоке try выбросил другой тип — FileNotFoundException . Для FileNotFoundException мы не написали сценарий, поэтому программа вывела в консоль ту информацию, которая выводится по умолчанию для FileNotFoundException . Здесь тебе нужно обратить внимание на 3 вещи. Первое. Как только в какой-то строчке кода в блоке try возникнет исключение, код после нее уже не будет выполнен. Выполнение программы сразу “перепрыгнет” в блок catch . Например: Вывод: В блоке try во второй строчке мы попытались разделить число на 0, в результате чего возникло исключение ArithmeticException . После этого строки 6-10 блока try выполнены уже не будут. Как мы и говорили, программа сразу начала выполнять блок catch . Второе. Блоков catch может быть несколько. Если код в блоке try может выбросить не один, а несколько видов исключений, для каждого из них можно написать свой блок catch . В этом примере мы написали два блока catch . Если в блоке try произойдет FileNotFoundException , будет выполнен первый блок catch . Если произойдет ArithmeticException , выполнится второй. Блоков catch ты можешь написать хоть 50. Но, конечно, лучше не писать код, который может выбросить 50 разных видов ошибок 🙂 Третье. Откуда тебе знать, какие исключения может выбросить твой код? Ну, про некоторые ты, конечно, можешь догадываться, но держать все в голове невозможно. Поэтому компилятор Java знает о самых распространенных исключениях и знает, в каких ситуациях они могут возникнуть. Например, если ты написал код и компилятор знает, что при его работе могут возникнуть 2 вида исключений, твой код не скомпилируется, пока ты их не обработаешь. Примеры этого мы увидим ниже. Теперь что касается обработки исключений. Существует 2 способа их обработки. С первым мы уже познакомились — метод может обработать исключение самостоятельно в блоке catch() . Есть и второй вариант — метод может выбросить исключение вверх по стеку вызовов. Что это значит? Например, у нас в классе есть метод — все тот же printFirstString() , который считывает файл и выводит в консоль его первую строку: На текущий момент наш код не компилируется, потому что в нем есть необработанные исключения. В строке 1 ты указываешь путь к файлу. Компилятор знает, что такой код легко может привести к FileNotFoundException . В строке 3 ты считываешь текст из файла. В этом процессе легко может возникнуть IOException — ошибка при вводе-выводе данных (Input-Output). Сейчас компилятор говорит тебе: “Чувак, я не одобрю этот код и не скомпилирую его, пока ты не скажешь мне, что я должен делать в случае, если произойдет одно из этих исключений. А они точно могут произойти, исходя из того кода, который ты написал!”. Деваться некуда, нужно обрабатывать оба! Первый вариант обработки нам уже знаком: надо поместить наш код в блок try , и добавить два блока catch : Но это не единственный вариант. Мы можем не писать сценарий для ошибки внутри метода, и просто пробросить исключение наверх. Это делается с помощью ключевого слова throws , которое пишется в объявлении метода: После слова throws мы через запятую перечисляем все виды исключений, которые этот метод может выбросить при работе. Зачем это делается? Теперь, если кто-то в программе захочет вызвать метод printFirstString() , он должен будет сам реализовать обработку исключений. К примеру, в другой части программы кто-то из твоих коллег написал метод, внутри которого вызывает твой метод printFirstString() : Ошибка, код не компилируется! В методе printFirstString() мы не написали сценарий обработки ошибок. Поэтому задача ложится на плечи тех, кто будет этот метод использовать. То есть перед методом yourColleagueMethod() теперь стоят те же 2 варианта: он должен или обработать оба исключения, которые ему “прилетели”, с помощью try-catch , или пробросить их дальше. Во втором случае обработка ляжет на плечи следующего по стэку метода — того, который будет вызывать yourColleagueMethod() . Вот поэтому такой механизм называется “пробрасыванием исключения наверх”, или “передачей наверх”. alt=»Исключения: перехват и обработка — 3″ width=»1024″ />Когда ты пробрасываешь исключения наверх с помощью throws , код компилируется. Компилятор в этот момент как бы говорит: “Окей, ладно. Твой код содержит кучу потенциальных исключений, но я, так и быть, его скомпилирую. Мы еще вернемся к этому разговору!” И когда ты где-то в программе вызываешь метод, который не обработал свои исключения, компилятор выполняет свое обещание и снова напоминает о них. В завершении мы поговорим о блоке finally (простите за каламбур). Это последняя часть триумвирата обработки исключений try-catch-finally . Его особенность в том, что он выполняется при любом сценарии работы программы. В этом примере код внутри блока finally выполняется в обоих случаях. Если код в блоке try выполнится целиком и не выбросит исключения, в конце сработает блок finally . Если код внутри try прервется, и программа перепрыгнет в блок catch , после того, как отработает код внутри catch , все равно будет выбран блок finally . Зачем он нужен? Его главное назначение — выполнить обязательную часть кода; ту часть, которая должна быть выполнена независимо от обстоятельств. Например, в нем часто освобождают какие-то используемые программой ресурсы. В нашем коде мы открываем поток для чтения информации из файла и передаем его в объект BufferedReader . Наш reader нужно закрыть и освободить ресурсы. Это нужно сделать в любом случае: неважно, отработает программа как надо или вызовет исключение. Это удобно делать в блоке finally : Теперь мы точно уверены, что позаботились о занятых ресурсах независимо от того, что произойдет при работе программы 🙂 Это еще не все, что тебе нужно знать об исключениях. Обработка ошибок — очень важная тема в программировании: ей посвящена не одна статья. На следующем занятии мы узнаем, какие бывают виды исключений и как создать свое собственное исключение:) До встречи!
What throws an IOException in Java?
java.io.IOException seems to be the most common type of exception, and coincidentally, it seems to also be the most ambiguous.
I keep seeing the throws IOException whenever writing with sockets, files, etc. I’ve never actually had one fired on me, however, so I’m wondering what it is that is supposed to fire the exception. The documentation isn’t very helpful in explaining what’s going on:
Signals that an I/O exception of some sort has occurred. This class is the general class of exceptions produced by failed or interrupted I/O operations.
What are some instances where an IOException would be thrown, and how is it supposed to be used?
3 Answers 3
Assume you were:
- Reading a network file and got disconnected.
- Reading a local file that was no longer available.
- Using some stream to read data and some other process closed the stream.
- Trying to read/write a file, but don’t have permission.
- Trying to write to a file, but disk space was no longer available.
There are many more examples, but these are the most common, in my experience.
In general, I/O means Input or Output. Those methods throw the IOException whenever an input or output operation is failed or interpreted. Note that this won’t be thrown for reading or writing to memory as Java will be handling it automatically.
Here are some cases which result in IOException .
- Reading from a closed inputstream
- Try to access a file on the Internet without a network connection
Java documentation is helpful to know the root cause of a particular IOException.
Just have a look at the direct known sub-interfaces of IOException from the documentation page:
ChangedCharSetException, CharacterCodingException, CharConversionException, ClosedChannelException, EOFException, FileLockInterruptionException, FileNotFoundException, FilerException, FileSystemException, HttpRetryException, IIOException, InterruptedByTimeoutException, InterruptedIOException, InvalidPropertiesFormatException, JMXProviderException, JMXServerErrorException, MalformedURLException, ObjectStreamException, ProtocolException, RemoteException, SaslException, SocketException, SSLException, SyncFailedException, UnknownHostException, UnknownServiceException, UnsupportedDataTypeException, UnsupportedEncodingException, UserPrincipalNotFoundException, UTFDataFormatException, ZipException
Most of these exceptions are self-explanatory.
A few IOExceptions with root causes:
EOFException: Signals that an end of file or end of stream has been reached unexpectedly during input. This exception is mainly used by data input streams to signal the end of the stream.
SocketException: Thrown to indicate that there is an error creating or accessing a Socket.
RemoteException: A RemoteException is the common superclass for a number of communication-related exceptions that may occur during the execution of a remote method call. Each method of a remote interface, an interface that extends java.rmi.Remote, must list RemoteException in its throws clause.
UnknownHostException: Thrown to indicate that the IP address of a host could not be determined (you may not be connected to Internet).
MalformedURLException: Thrown to indicate that a malformed URL has occurred. Either no legal protocol could be found in a specification string or the string could not be parsed.