Интеграция XML в Java [дубликат]

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

См. также: A хороший список лучших практик

Я бы добавил, очень важно, хорошо использовать модификатор final. Использование "окончательной" модификатор, когда это применимо в Java

Сводка:

  1. Используйте модификатор final для обеспечения хорошей инициализации.
  2. Избегайте возврата null в методы, например, при возврате пустых коллекций.
  3. Использовать аннотации @NotNull и @Nullable
  4. Быстрое завершение работы и использование утверждений, чтобы избежать распространения нулевых объектов через все приложение, когда они не должен быть пустым.
  5. Сначала используйте значения с известным объектом: if("knownObject".equals(unknownObject)
  6. Предпочитают valueOf() поверх toString ().
  7. Используйте null safe StringUtils StringUtils.isEmpty(null).

60
задан user2864740 1 September 2014 в 21:56
поделиться

6 ответов

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

enter image description here [/g3]

В Java вы можете выбросить все, что расширяет класс Throwable. Однако вам не нужно указывать предложение throws для всех классов. В частности, классы, которые являются либо Error, либо RuntimeException или любым из подклассов этих двух. В вашем случае Exception не является подклассом Error или RuntimeException. Таким образом, это проверенное исключение и должно быть указано в предложении throws, если вы не обрабатываете это конкретное исключение. Вот почему вам понадобилось предложение throws.


Из Учебник по Java :

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

Теперь, как вы знаете, исключения классифицируются на два: отмечены и не отмечены. Почему эта классификация?

Проверено исключение: они используются для представления проблем, которые могут быть восстановлены во время выполнения программы. Обычно они не являются ошибкой программиста. Например, файл, указанный пользователем, недоступен для чтения или недоступен для сетевого подключения и т. Д. Во всех этих случаях нашей программе не нужно выходить, вместо этого она может предпринимать действия, такие как предупреждение пользователя, или переход в резервный механизм (например, работа в автономном режиме, когда сеть недоступна) и т. д.

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

  • Исключения времени выполнения: они обычно происходят из-за ошибки программистов. Например, если происходит ArithmeticException деления на ноль или происходит ArrayIndexOutOfBoundsException, это происходит потому, что мы недостаточно осторожны в нашем кодировании. Обычно они происходят из-за некоторых ошибок в нашей программной логике. Поэтому они должны быть очищены до того, как наша программа войдет в производственный режим. Они неконтролируемы в том смысле, что наша программа должна потерпеть неудачу, когда это произойдет, чтобы программисты могли ее решить во время разработки и тестирования.
  • Ошибки: Ошибки - это ситуации, из-за которых обычно программа не может выздороветь. Например, если возникает StackOverflowError, наша программа не может сделать многого, например, увеличить размер функции вызова вызова программы. Или, если происходит OutOfMemoryError, мы не можем много сделать для увеличения объема оперативной памяти, доступной нашей программе. В таких случаях лучше выйти из программы.

Подробную информацию см. В:

104
ответ дан Armin 17 August 2018 в 14:34
поделиться
  • 1
    то, что я получил от вашего ответа, это то, что класс Error и его подклассы и класс RuntimeException и его подклассы, они попадают под неконтролируемое исключение (например, System.out.println (5/0), нет необходимости бросать, поскольку это но все же мы можем применить try catch), и класс Exception проверен, поэтому нам нужно объявить предложение throws в этом методе и каждый метод, который его вызывает – nr5 21 July 2012 в 05:45
  • 2
    @ rd4code Или мы должны обрабатывать их с помощью try ... catch. – Jomoos 21 July 2012 в 05:47
  • 3
    Еще один вопрос: если исключения классифицируются как неконтролируемые и проверенные, особенно непроверенные (ошибки времени выполнения), чтобы избежать большего количества ошибок во время компиляции? – nr5 21 July 2012 в 06:04
  • 4
    @ rd4code Просмотреть обновленный ответ – Jomoos 21 July 2012 в 07:41
  • 5
    @Jomoos - Скажите, что код внутри метода вызывает IOException. Тогда, можно ли положить «Бросок Исключения»? в объявлении метода? – testerjoe2 5 December 2017 в 07:54
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 в сигнатуре метода.

0
ответ дан Aditya 17 August 2018 в 14:34
поделиться

Объявление throws Exception является автоматизированным способом отслеживания методов, которые могут генерировать исключение по ожидаемым, но неизбежным причинам. Обычно декларация относится к типу или типам исключений, которые могут быть выбраны, например throws IOException или throws IOException, MyException.

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

Когда программист знает, что могут возникнуть определенные типы ошибок, но они хотели бы обрабатывать эти исключения вне метода, метод может «выбросить» один или несколько типов исключений из вызывающего метода вместо их обработки. Если программист не заявлял, что метод (может) генерирует исключение (или если у Java не было возможности объявить его), компилятор не мог знать, и это может быть связано с будущим пользователем метода, улавливать и обрабатывать любые исключения, которые может бросить метод. Поскольку программы могут иметь много уровней методов, написанных многими различными программами, становится трудно (невозможно) отслеживать, какие методы могут генерировать исключения.

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

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

Приятное дело в этом типе решения заключается в том, что когда компилятор сообщает Error: Unhandled exception type java.io.IOException, он дает номер файла и строки метода, который был объявлен для исключения исключения. Затем вы можете просто просто передать доллар и объявить свой метод также «бросает IOException». Это можно сделать вплоть до основного метода, в результате чего программа остановится и сообщит об этом пользователю. Тем не менее, лучше поймать исключение и справиться с ним красиво, например, объяснить пользователю, что произошло, и как его исправить. Когда метод выполняет catch и обрабатывает исключение, ему больше не нужно объявлять исключение. Бак останавливается там, чтобы говорить.

3
ответ дан dansalmo 17 August 2018 в 14:34
поделиться

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» в объявлении метода.

20
ответ дан jebar8 17 August 2018 в 14:34
поделиться
  • 1
    Все исключения, которые не являются подклассами RuntimeException, то есть. – yshavit 21 July 2012 в 05:25
  • 2
    если существует какой-либо другой класс, например Exception? – nr5 21 July 2012 в 06:12
  • 3
    Что вы имеете в виду? Поскольку все объекты исключений имеют «Исключение», как их базовый класс, если вы поймаете «Исключение», объект (как в моем примере), он поймает любое исключение, которое будет выбрано. Чтобы быть более конкретным (поскольку для разных исключений, вероятно, потребуются разные способы обработки вещей), вы должны иметь несколько блоков catch. – jebar8 21 July 2012 в 06:19
  • 4
    если бы я сказал, что проверенные исключения нужно обрабатывать @ время компиляции и попадать во время выполнения. Я прав ? если да, то будет ли фраза о том же предложении для исключения без отметки? – nr5 21 July 2012 в 06:22
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», даже если не тот же метод, где исключение происходит.

0
ответ дан tawess 17 August 2018 в 14:34
поделиться

Exception - проверенный класс исключений. Поэтому любой код, вызывающий метод, объявляющий, что он throws Exception должен обрабатывать или объявлять его.

3
ответ дан Taymon 17 August 2018 в 14:34
поделиться
  • 1
    Каждому методу в цепочке объявляется throw Exception, в том числе main. Итак, где проблема? – Paul Tomblin 21 July 2012 в 05:09
  • 2
  • 3
    Хорошо, я не понял, почему вы спрашивали о ошибке компилятора, которую вы фактически не получали из кода, который вы опубликовали. Это странный способ спросить. – Paul Tomblin 21 July 2012 в 05:15
Другие вопросы по тегам:

Похожие вопросы: