Многие объяснения уже присутствуют, чтобы объяснить, как это происходит и как это исправить, но вы также должны следовать рекомендациям, чтобы избежать NullPointerException
вообще.
См. также: A хороший список лучших практик
Я бы добавил, очень важно, хорошо использовать модификатор final
. Использование "окончательной" модификатор, когда это применимо в Java
Сводка:
final
для обеспечения хорошей инициализации. @NotNull
и @Nullable
if("knownObject".equals(unknownObject)
valueOf()
поверх toString (). StringUtils
StringUtils.isEmpty(null)
. В Java, как вы знаете, исключения могут быть разделены на две части: одна, которая нуждается в предложении throws
или должна обрабатываться, если вы не укажете один и другой, который этого не делает. Теперь см. Следующий рисунок:
[/g3]
В Java вы можете выбросить все, что расширяет класс Throwable
. Однако вам не нужно указывать предложение throws
для всех классов. В частности, классы, которые являются либо Error
, либо RuntimeException
или любым из подклассов этих двух. В вашем случае Exception
не является подклассом Error
или RuntimeException
. Таким образом, это проверенное исключение и должно быть указано в предложении throws
, если вы не обрабатываете это конкретное исключение. Вот почему вам понадобилось предложение throws
.
Из Учебник по Java :
Исключение - это событие, которое происходит во время выполнения программы, что нарушает нормальный поток инструкций программы.
blockquote>Теперь, как вы знаете, исключения классифицируются на два: отмечены и не отмечены. Почему эта классификация?
Проверено исключение: они используются для представления проблем, которые могут быть восстановлены во время выполнения программы. Обычно они не являются ошибкой программиста. Например, файл, указанный пользователем, недоступен для чтения или недоступен для сетевого подключения и т. Д. Во всех этих случаях нашей программе не нужно выходить, вместо этого она может предпринимать действия, такие как предупреждение пользователя, или переход в резервный механизм (например, работа в автономном режиме, когда сеть недоступна) и т. д.
Непроверенные исключения: их снова можно разделить на два: Ошибки и Исключения RuntimeExceptions. Одной из причин, по которым они должны быть сняты, является то, что они многочисленны и требуются для обработки всех из них, будут загромождать нашу программу и уменьшать ее ясность. Другая причина такова:
- Исключения времени выполнения: они обычно происходят из-за ошибки программистов. Например, если происходит
ArithmeticException
деления на ноль или происходитArrayIndexOutOfBoundsException
, это происходит потому, что мы недостаточно осторожны в нашем кодировании. Обычно они происходят из-за некоторых ошибок в нашей программной логике. Поэтому они должны быть очищены до того, как наша программа войдет в производственный режим. Они неконтролируемы в том смысле, что наша программа должна потерпеть неудачу, когда это произойдет, чтобы программисты могли ее решить во время разработки и тестирования.- Ошибки: Ошибки - это ситуации, из-за которых обычно программа не может выздороветь. Например, если возникает
StackOverflowError
, наша программа не может сделать многого, например, увеличить размер функции вызова вызова программы. Или, если происходитOutOfMemoryError
, мы не можем много сделать для увеличения объема оперативной памяти, доступной нашей программе. В таких случаях лучше выйти из программы.Подробную информацию см. В:
void show() throws Exception
{
throw new Exception("my.own.Exception");
}
Поскольку в методе show () исключено исключение, которое не обрабатывается в этом методе, поэтому мы используем ключевое слово throw для распространения Исключения.
void show2() throws Exception //Why throws is necessary here ?
{
show();
}
Поскольку вы используете show () в методе show2 (), и вы распространяли исключение, по крайней мере, вы должны здесь обращаться. Если вы не обрабатываете Исключение здесь, вы используете ключевое слово throw. Таким образом, это причина использования ключевого слова throw в сигнатуре метода.
Объявление throws Exception
является автоматизированным способом отслеживания методов, которые могут генерировать исключение по ожидаемым, но неизбежным причинам. Обычно декларация относится к типу или типам исключений, которые могут быть выбраны, например throws IOException
или throws IOException, MyException
.
Мы все или в конце концов напишем код, который неожиданно останавливается и сообщает об исключении из-за чего мы не ожидали до запуска программы, например деления на ноль или индекса за пределами. Поскольку ошибки не ожидались с помощью метода, они не могли быть «пойманы» и обработаны предложением try catch. Любые ничего не подозревающие пользователи этого метода также не знают об этой возможности, и их программы также прекратятся.
Когда программист знает, что могут возникнуть определенные типы ошибок, но они хотели бы обрабатывать эти исключения вне метода, метод может «выбросить» один или несколько типов исключений из вызывающего метода вместо их обработки. Если программист не заявлял, что метод (может) генерирует исключение (или если у Java не было возможности объявить его), компилятор не мог знать, и это может быть связано с будущим пользователем метода, улавливать и обрабатывать любые исключения, которые может бросить метод. Поскольку программы могут иметь много уровней методов, написанных многими различными программами, становится трудно (невозможно) отслеживать, какие методы могут генерировать исключения.
Несмотря на то, что Java имеет возможность объявлять исключения, вы все равно можете написать новый метод с необработанными и необъявленными исключениями, а Java будет скомпилировать его, и вы сможете запустить его и надеяться на лучшее. То, что Java не позволит вам сделать, - это скомпилировать ваш новый метод, если он использует метод, объявленный как исключение (исключения) исключения, если вы не обрабатываете объявленное исключение (исключения) в своем методе или не объявляете свой метод как бросание того же исключение (исключения) или если есть несколько исключений, вы можете обрабатывать некоторые и бросать остальные.
Когда программист заявляет, что метод генерирует конкретный тип исключения, это просто автоматический способ предупредить других программистов, используя метод, чтобы исключение было возможным. Затем программист может решить обработать исключение или передать предупреждение, объявив вызывающий метод, также выдавая одно и то же исключение. Поскольку компилятор был предупрежден, исключение возможно в этом новом методе, оно может автоматически проверять, обрабатывают ли будущие вызывающие элементы нового метода исключение или объявляют его и принуждают тот или иной случай.
Приятное дело в этом типе решения заключается в том, что когда компилятор сообщает Error: Unhandled exception type java.io.IOException
, он дает номер файла и строки метода, который был объявлен для исключения исключения. Затем вы можете просто просто передать доллар и объявить свой метод также «бросает IOException». Это можно сделать вплоть до основного метода, в результате чего программа остановится и сообщит об этом пользователю. Тем не менее, лучше поймать исключение и справиться с ним красиво, например, объяснить пользователю, что произошло, и как его исправить. Когда метод выполняет catch и обрабатывает исключение, ему больше не нужно объявлять исключение. Бак останавливается там, чтобы говорить.
Java требует, чтобы вы обрабатывали или объявляли все исключения. Если вы не обрабатываете исключение, используя блок try / catch, он должен быть объявлен в сигнатуре метода.
Например:
class throwseg1 {
void show() throws Exception {
throw new Exception();
}
}
Должен быть записан как:
class throwseg1 {
void show() {
try {
throw new Exception();
} catch(Exception e) {
// code to handle the exception
}
}
}
Таким образом вы можете избавиться от объявления «throws Exception» в объявлении метода.
RuntimeException
, то есть.
– yshavit
21 July 2012 в 05:25
package javaexception;
public class JavaException {
void show() throws Exception
{
throw new Exception("my.own.Exception");
}
void show2() throws Exception // Why throws is necessary here ?
{
show();
}
void show3() throws Exception // Why throws is necessary here ?
{
show2();
}
public static void main(String[] args) {
JavaException a = new JavaException();
try{
a.show3();
}catch(Exception e){
System.out.println(e.getMessage());
}
}
Только небольшие изменения в вашей программе. Кажется, что многие неправильно понимают основную проблему, когда вы делаете исключение, которое вам нужно обрабатывать, не обязательно в одном месте (например, метод show1,2,3 в вашей программе), но вы должны сначала использовать метод вызова внутри «основного». одним словом, существует «бросок», должен быть «catch / try», даже если не тот же метод, где исключение происходит.
Exception
- проверенный класс исключений. Поэтому любой код, вызывающий метод, объявляющий, что он throws Exception
должен обрабатывать или объявлять его.
try ... catch
. – Jomoos 21 July 2012 в 05:47