Считается ли вышеизложенное проверенным исключением?
нет
Тот факт, что вы обрабатываете исключение, не делает его Checked Exception, если оно RuntimeException.
Является ли RuntimeException unchecked exception?
Да
Checked Exceptions являются subclasses из java.lang.Exception
Unchecked Exceptions являются subclasses из java.lang.RuntimeException
Вызовы, выбрасывающие проверенные исключения, должны быть заключены в блок try {} или обработаны на уровне выше в вызывающей стороне метода. В этом случае текущий метод должен объявить, что он вызывает указанные исключения, чтобы вызывающие могли принять соответствующие меры для обработки исключения.
Надеюсь, это поможет.
Q: я должен всплыть точно
исключение или замаскировать его с помощью исключения?
A: Да, это очень хороший вопрос и важное соображение дизайна. Класс Exception является очень общим классом исключений и может использоваться для переноса внутренних исключений низкого уровня. Вам лучше создать собственное исключение и обернуть его внутри. Но, и главное: никогда не скрывать первопричину первопричины. Например, Don't ever выполните следующие действия -
try {
attemptLogin(userCredentials);
} catch (SQLException sqle) {
throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}
Вместо этого сделайте следующее:
try {
attemptLogin(userCredentials);
} catch (SQLException sqle) {
throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}
Уничтожение первоначальной первопричины скрывает фактическую причину, выходящую за рамки восстановления, - это кошмар для рабочих групп поддержки, к которым у них есть доступ только к журналам приложений и сообщениям об ошибках.
Хотя последний вариант лучше, но многие люди не используют его часто, потому что разработчики просто не могут передать исходное сообщение вызывающей стороне. Поэтому сделайте твёрдое замечание: Always pass on the actual exception верните, завернуто или нет в какое-либо исключение для конкретного приложения.
При попытке поймать RuntimeExceptions
RuntimeException s, как правило, не следует пытаться поймать. Они обычно сигнализируют об ошибке программирования и должны быть оставлены в покое. Вместо этого программист должен проверить состояние ошибки, прежде чем вызывать некоторый код, который может привести к RuntimeException. Например:
try {
setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
sendError("Sorry, your userObject was null. Please contact customer care.");
}
Это плохая практика программирования. Вместо этого следует выполнить нулевую проверку, как -
if (userObject != null) {
setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
sendError("Sorry, your userObject was null. Please contact customer care.");
}
Но бывают случаи, когда такая проверка ошибок стоит дорого, например, при форматировании чисел, учтите это -
try {
String userAge = (String)request.getParameter("age");
userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}
Здесь проверка ошибок перед вызовом не стоит усилий, потому что по сути это означает дублирование всего кода преобразования строки в целое в методе parseInt () - и подвержена ошибкам, если реализована разработчиком. Так что лучше просто покончить с try-catch.
Так что NullPointerException и NumberFormatException оба RuntimeExceptions, перехват NullPointerException должен быть заменен изящной нулевой проверкой, в то время как я рекомендую явно перехватывать NumberFormatException, чтобы избежать возможного введения подверженного ошибкам кода.