Действительно ли хорошо поймать более общий тип Исключения?

Как правило, вы должны перехватывать только исключения, которые вы собираетесь обрабатывать явно.

Вы не должны перехватывать Exception, IOException и т. Д. и др., если только вы не находитесь на достаточно высоком уровне, когда вы делаете свой последний улов, чтобы сообщить пользователю об общей ошибке.

Неполноценный перехват любого исключения - не лучшая идея. Да, как родительское исключение, похоже, обеспечивает уровень «защиты», но это плохо по нескольким причинам:

IOExceptions проверяются. Если в коде нет ничего, что бросало бы его, добавление ненужного улова просто скрывает вещи и, скорее всего, запутает любого, кто позже посмотрит код.

Что еще более важно, вы не улавливаете исключения, чтобы просто заставить их исчезнуть. Если это так, вы можете просто обернуть все свои методы в (catch (Exception e) {..}) и покончить с этим. Ваш код перехвата исключений должен быть тем местом, где вы решаете, что делать в случае возникновения этих ошибок, например

catch(FileNotFoundException e)
{
 log.error("where's the file?");return null;
}
catch(ZipException e)
{
 log.error("corrupt");return null;
}

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

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

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

Но чтобы ответить прямо на ваш вопрос, IOException может быть на соответствующем уровне. Вам может быть достаточно знать, что какая бы проблема ни была, она связана с вводом-выводом, и вы можете действовать в соответствии с ней. Без дополнительной информации сложно сказать.

Если есть сомнения, всегда перехватывает более конкретное исключение!

Как хороший консультант, я говорю «это зависит от обстоятельств»

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

} catch (Exception e){
   // log or stack trace
}

... в более или менее одноразовом коде. Однако в целом не следует перехватывать исключение, с которым вы не знаете, как с пользой обработать. (Никогда, никогда никогда , не делайте catch (Exception x); , т. Е. Просто отбрасывайте исключение. Никогда.)

Главное - спросить: «Что я могу делать с этим? " Часто исключение «файл не найден» можно обработать, спросив пользователя, куда пропал его файл. Исключение из zip-файла сложнее обработать. Таким образом, вы можете захотеть иметь разные варианты поведения.

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

Еще один совет; не выводите трассировку стека в коде, ориентированном на клиента - код, который может увидеть непрограммист. Непрограммисты склонны смотреть на завершенность трассировки стека и паниковать. Лучше преобразовать исключение в сообщение типа «Файл 'имя_файла' не найден». и, если вам действительно нужна трассировка стека, отключите ведение журнала, чтобы отправить его на вывод уровня отладки.

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

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

Я думаю, это вопрос личных предпочтений. Лично мне кажется, что это не лучший выбор. Я предпочитаю иметь код, который имеет смысл для меня с элементами try-catch. Это означает, что нужно быть максимально конкретным. Я бы сказал:

try{
    //Code Here
}
catch(FileNotFoundException e){
    //Code Here
}

Это зависит от того, будет ли более конкретное исключение помощь в устранении неисправностей. Иногда, как в случае с JMX, полезно просто перехватить родительское исключение, чтобы избежать длинного списка возможных дочерних исключений. По крайней мере, Java 7 позволит нам иметь более одного исключения на каждый улов. Это немного очистит код.

Я повторю «поймать наиболее конкретное исключение, которое вы можете».

Я обычно перехватываю IOException и показываю какое-то сообщение «ошибка чтения файла», а затем позволяю пользователю выбрать другое файл или что-то подходящее. Если файл действительно плохой, пользователь, вероятно, мало что может с этим поделать, но, по крайней мере, вы можете сообщить им, что файл плохой.

Если вы получите FileNotFoundException, настоящая проблема почти наверняка в том, что пользователь выбрал неправильное имя файла или жестко заданное имя файла больше не действует. Я обычно показываю для этого сообщения.

Я почти никогда не улавливаю «Исключение». Что вы собираетесь с этим делать? Вы практически ничего не можете сделать, чтобы восстановиться после того, как «что-то пошло не так, но более подробная информация недоступна».