В недавнем проекте я рекомендовал уловить исключение RuntimeException в коде тестового жгута и занести его в журнал. Код обрабатывает ряд входов из базы данных, и я не хочу, чтобы тест останавливался из-за отказа какого-либо ввода (значения Null, недопустимые аргументы и т.д.). Излишне говорить, что мое предложение вызвало страстное обсуждение.
Улавливает ли какое-либо исключение RuntimeException? Если да, то каковы другие сценарии, где это нормально, чтобы поймать RuntimeExceptions?
Вы поймаете RuntimeException по той же причине, что и вы поймаете какое-либо исключение: вы планируете что-то с этим сделать. Возможно, вы можете исправить все, что вызвало исключение. Возможно, вы просто хотите перебросить с другим типом исключения.
Уловка и игнорирование каких-либо исключений, однако, крайне плохая практика.
Если вы не можете исправить исключение RuntimeException, вы не хотите его ловить...
... только true с точки зрения разработчиков....
вам нужно поймать все исключения, прежде чем они достигнут пользовательского интерфейса и сделают ваш пользователь печальным. Это означает, что на "самом высоком уровне" вы хотите поймать все, что происходит дальше. Затем вы можете сообщить пользователю о том, что есть проблема, и в то же время принять меры для информирования разработчиков, таких как отправка сообщений о тревоге или что-то еще...
В основном считается ошибкой данных/программирования, которая не может быть показана, поэтому вы хотите улучшить будущие выпуски программного обеспечения, в то же время взять пользователя за руку и двигаться контролируемым образом...
RuntimeException предназначен для использования для ошибок программиста. Как таковой он никогда не должен быть пойман. Есть несколько случаев, когда это должно быть:
вы вызываете код, который поступает от третьей стороны, где вы не имеете контроля над тем, когда они генерируют исключение. Я бы сказал, что вы должны делать это в каждом конкретном случае и обернуть использование стороннего кода в своих собственных классах, чтобы вы могли передавать обратно исключения без выполнения.
ваша программа не может сбой и оставить трассировку стека для просмотра пользователем. В этом случае он должен перемещаться по главному и вокруг любого потока и кода обработки событий. Вероятно, программа должна выйти, когда такое исключение также произойдет.
В вашем конкретном случае мне придется задаться вопросом, почему вы испытываете RuntimeExceptions в тестах - вы должны исправлять их, а не работать вокруг них.
Таким образом, вы должны гарантировать, что ваш код генерирует только RuntimeExceptions, когда вы хотите выйти из программы. Вы должны только перехватывать RuntimeExceptions, когда вы хотите зарегистрировать его и выйти. Это то, что соответствует намерениям RuntimeExceptions.
Вы можете посмотреть эту дискуссию по другим причинам, которые люди дают... Я лично не нашел в ответах убедительной причины.
Несколько лет назад мы написали структуру системы управления, а объекты-агенты захватили исключения во время выполнения, зарегистрировали их, если могли, и продолжили.
Да, мы поймали исключения Runtime, в том числе OutOfMemory, в нашем коде кода (и вынудили GC, и это удивительно, насколько хорошо это поддерживало даже довольно пропущенный код). У нас был код, который делал очень математические вещи, связанные с реальным миром; и время от времени Not-A-Number получал бы из-за крошечных ошибок округления, и он тоже справлялся с этим.
Итак, в рамках/ "не должен выходить" код, я думаю, он может быть оправданным. И когда это работает, это довольно круто.
Код был довольно прочным, но он работал с аппаратным обеспечением, а аппаратное обеспечение иногда давало отвратительные ответы.
Он был разработан, чтобы работать без вмешательства человека в течение нескольких месяцев. Он очень хорошо работал в наших тестах.
В рамках кода восстановления ошибок он может прибегнуть к перезагрузке всего здания, используя возможность ИБП отключить через N минут и включиться в течение M минут.
Иногда аппаратные неисправности должны быть задействованы:)
Если я помню, последнее средство после неудачного силового цикла заключалось в том, что он отправил ему письмо своим владельцам, сказав: "Я попытался исправить себя, и я не могу, проблема в подсистеме XYZ" и включила ссылку для вызова обратного вызова нам.
К сожалению, проект получил консервы, прежде чем он смог осознать себя:) >
В моем коде 99% моих исключений выведены из runtime_exception.
Причины, по которым я перехватываю исключения:
Лично мне всегда говорили, что вы хотите поймать все RuntimeExceptions; однако вы также хотите сделать что-то о исключение, например, запустить отказоустойчивое или, возможно, просто проинформировать пользователя об ошибке.
Последний проект Java, над которым я работал, имел похожий подход, по крайней мере, мы могли бы регистрировать исключение, чтобы, если пользователь вызывал жалобы на ошибку, мы могли точно выяснить, что произошло, и увидеть, где произошла ошибка.
Изменить 1: Как сказал kdgregory, улов и игнорирование - это две разные вещи, как правило, люди против последнего: -)
Мы все знаем, что проверенные исключения и RuntimeExceptions являются двумя категориями исключений. Всегда рекомендуется, чтобы мы обрабатывали (либо try-catch или throw) проверенные исключения, потому что они являются условиями программирования, где, к сожалению, программист не может ничего делать сам по себе;
Например, FileNotFoundException не программист помещает файлы на пользовательский диск, если программа на самом деле пытается прочитать файл 1.txt, который должен находиться на f:\ пользователя с инструкциями:
File f11 = new File("f:\\1.txt");
FileInputStream fos = new FileInputStream(f11);
Если файл найден, все в порядке, но что происходит в другом случае, если файл не найден, это значит, что программа сбрасывает с ошибкой 0 от пользователя. В этом сценарии программист не сделал ничего плохого. Это может быть проверенное исключение, которое необходимо поймать для продолжения работы программы.
Позвольте мне также объяснить второй сценарий, с которым будет ясно понятие RuntimeException. Рассмотрим следующий код:
int a = {1,2,3,4,5};
System.out.println(a[9]);
Это плохое кодирование, которое генерирует ArrayIndexOutOfBoundsException. Это пример RuntimeException. Таким образом, программист не должен фактически обрабатывать исключение, разрешить ему сбой программы, а затем исправить логику.
Вы ловите RuntimeException, когда хотите его обработать. Возможно, вы хотите изменить его как другое исключение или зарегистрировать его в файле или базе данных или хотите включить флаг исключения в возвращаемом типе и т.д.
Вы улавливаете RuntimeExceptions (на любом языке: неожиданные исключения/исключения "все" ), когда ваша программа выполняет несколько подзадач, и имеет смысл завершить все, что вы можете, а не останавливаться на первой неожиданной ситуации. Набор тестов - прекрасная ситуация для этого - вы хотите знать, какой из всех тестов не удался, а не только первый тест. Ключевой характеристикой является то, что каждый тест не зависит от всех остальных - не имеет значения, не выполняется ли предыдущий тест, потому что порядок не имеет значения.
Другая распространенная ситуация - сервер; вы не хотите закрывать только потому, что один запрос был искажен так, как вы этого не ожидали. (Если это действительно действительно важно, чтобы свести к минимуму вероятность несогласованного состояния.)
В любой из этих ситуаций необходимо сделать следующее: log/report the exception и продолжить выполнение оставшихся задач.
Можно было бы смутно обобщить любое исключение: "уместно ловить" исключение, если и только если есть что-то разумное делать после того, как поймать его: как ваша программа должна продолжаться.
Если клиент может разумно ожидать восстановления из исключения, сделайте это проверенным исключением.
Если клиент не может ничего сделать для восстановления из исключения, сделайте его незафиксированным исключением.
Ниже приведена ориентировочная строка.
Из Java Docs. Пожалуйста, прочитайте это Unchecked Exceptions - The Controversy