2010-07-29 2 views
8

Есть ли способ программно отличить то, что вызвало IOException? Например, java будет генерировать исключение IOException, если во время записи была ошибка. Как я могу сказать, если это что-то вроде нарушения прав доступа, если на диске нет свободного места, если кто-то отключил сетевой диск или другие вещи.Программно определить причину IOException?

Я не могу разобрать сообщение, поскольку, похоже, нет стандартизованного формата сообщений, Sun (или оракул теперь, я думаю), похоже, не имеет стандартного формата.

Все предложения (Я довольно новыми для Java, его не мой нормальный язык, но мне нужно, чтобы использовать его, чтобы исправить очень сломанную систему на работе.)

ответ

5

К сожалению, Java не имеет эквивалента .NET-х System.Runtime.InteropServices.Marshal.GetHRForException(). Вы сообщаете, какая ошибка ввода-вывода была только в том случае, если это исключение является экземпляром подкласса, например. FileNotFoundException.

+0

Возможно, это не то, что я хотел услышать = (но вы ответили мне). – UberJumper

0

Получение удержания точного класса исключения даст вам одну из нескольких возможных подклассов IOException, и они вполне стандартизированы. Вы можете либо тестировать классы с instanceof, либо (грубый подход) сравнить строки, возвращенные с getClass().getName().

Есть некоторые способы обхода других вещей; вы можете сделать File.canWrite() на файл, который вы собираетесь открыть для записи (ну, ваша программа должна была это сделать в любом случае, если имя и/или каталог могут меняться), и если есть шанс, что у вас закончилось файловое пространство, вы можете попробовать написать небольшой файл в известное хорошее место и посмотреть, если это взрывается на вас. Не очень элегантный, я знаю: Java на самом деле не известен как язык системного программирования.

С другой стороны, очень часто знание подробной причины исключения не очень помогает: с пониманием или без знания ваш пользователь просто не сможет заставить программу делать то, что необходимо.

+3

Возможное дополнение к вашему первому абзацу - как правило, вы «поймаете» эти исключения, поэтому лучше выбрать отдельный улов блоки для «FileNotFoundException», «UnknownHostException» и т. д. Он избегает «явного» тестирования и позволяет обрабатывать специальные случаи в разных блоках с самого начала (без исключения блокировки catch-all «catch (IOException e)» в конце) –

+0

@Ahdrzej: Вы очень правы. Я думал об исправлениях с помощью бандажей для ранее существовавшей кодировки и предполагал, что uberjumper не хочет переустанавливать существующие иерархии улов (независимо от того, что может быть). Но если «делать это правильно "- это вариант, тогда ваш путь был бы таким. –

Смежные вопросы