query () в поставщике контента [дубликат]

Я отправляю этот ответ, поэтому самый верхний ответ (при сортировке по активности) - это не тот, который просто ошибочен.

Что такое Stacktrace?

Stacktrace - это очень полезный инструмент отладки. Он показывает стек вызовов (значение, стек функций, которые были вызваны до этой точки) в то время, когда было выбрано неперехваченное исключение (или время, когда стек была создана вручную). Это очень полезно, потому что оно не только показывает вам, где произошла ошибка, но также и то, как программа оказалась в этом месте кода. Это приводит к следующему вопросу:

Что такое исключение?

Исключение - это то, что среда выполнения использует, чтобы сообщить вам, что произошла ошибка. Популярные примеры: NullPointerException, IndexOutOfBoundsException или ArithmeticException. Каждый из них вызывается, когда вы пытаетесь сделать что-то, что невозможно. Например, при попытке разыменовать Null-объект будет выбрано исключение NullPointerException:

Object a = null;
a.toString();                 //this line throws a NullPointerException

Object[] b = new Object[5];
System.out.println(b[10]);    //this line throws an IndexOutOfBoundsException,
                              //because b is only 5 elements long
int ia = 5;
int ib = 0;
ia = ia/ib;                   //this line throws an  ArithmeticException with the 
                              //message "/ by 0", because you are trying to
                              //divide by 0, which is not possible.

Как мне обращаться со Stacktraces / Exceptions?

Сначала выясните, что вызывает исключение. Попробуйте googleing имя исключения, чтобы узнать, в чем причина этого исключения. В большинстве случаев это будет вызвано неправильным кодом. В приведенных выше примерах все исключения вызваны неправильным кодом. Поэтому для примера NullPointerException вы можете убедиться, что a никогда не является нулевым в то время. Например, вы можете инициализировать a или включить проверку, подобную этой:

if (a!=null) {
    a.toString();
}

Таким образом, строка нарушения не выполняется, если a==null. То же самое касается других примеров.

Иногда вы не можете убедиться, что вы не получите исключения. Например, если вы используете сетевое соединение в своей программе, вы не можете остановить компьютер от потери его интернет-соединения (например, вы не можете запретить пользователю отключать сетевое подключение компьютера). В этом случае сетевая библиотека, вероятно, выбросит исключение. Теперь вы должны поймать исключение и обработать его. Это означает, что в примере с сетевым соединением вы должны попытаться снова открыть соединение или уведомить пользователя или что-то в этом роде. Кроме того, всякий раз, когда вы используете catch, всегда поймайте только исключение, которое вы хотите поймать, не используйте широко распространенные выписки, такие как catch (Exception e), которые поймают все исключения. Это очень важно, потому что в противном случае вы случайно поймаете неправильное исключение и отреагируете неверно.

try {
    Socket x = new Socket("1.1.1.1", 6789);
    x.getInputStream().read()
} catch (IOException e) {
    System.err.println("Connection could not be established, please try again later!")
}

Почему я не должен использовать catch (Exception e)?

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

int mult(Integer a,Integer b) {
    try {
        int result = a/b
        return result;
    } catch (Exception e) {
        System.err.println("Error: Division by zero!");
        return 0;
    }
}

Что этот код пытается сделать, так это поймать ArithmeticException, вызванное возможным делением на 0. Но он также ловит возможно NullPointerException, который выбрасывается, если a или b являются null. Это означает, что вы можете получить NullPointerException, но вы будете рассматривать его как исключение ArithmeticException и, вероятно, ошибаетесь. В лучшем случае вы все еще пропустите, что было исключение NullPointerException.

TLDR

1. Выясните, в чем причина исключения, и исправьте его, чтобы он не делал этого. 't исключение вообще.
2. Если 1. невозможно, поймайте конкретное исключение и обработайте его. Никогда не добавляйте try / catch, а затем просто игнорируйте исключение! Не делай этого! Никогда не используйте catch (Exception e), всегда улавливайте определенные Исключения. Это избавит вас от многих головных болей.

Чтобы добавить к другим примерам, есть внутренние (вложенные) классы, которые появляются с знаком $. Например:

public class Test {

    private static void privateMethod() {
        throw new RuntimeException();
    }

    public static void main(String[] args) throws Exception {
        Runnable runnable = new Runnable() {
            @Override public void run() {
                privateMethod();
            }
        };
        runnable.run();
    }
}

приведет к этой трассировке стека:

Exception in thread "main" java.lang.RuntimeException
        at Test.privateMethod(Test.java:4)
        at Test.access$000(Test.java:1)
        at Test$1.run(Test.java:10)
        at Test.main(Test.java:13)

Чтобы понять имя: трассировка стека представляет собой список исключений (или вы можете сказать список «Причина от»), от самого поверхностного исключения (например, исключение уровня обслуживания) до самого глубокого (например, исключения базы данных) , Точно так же, как причина, которую мы называем «стеком», состоит в том, что стек - это First in Last out (FILO), самое глубокое исключение произошло в самом начале, затем цепочка исключений была сгенерирована серией последствий, поверхность Exception была последней один из них произошел вовремя, но мы его видим в первую очередь.

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

-> Определить основную причину в середине - это ваша задача.

Ключ 2: Еще одна сложная, но важная вещь находится внутри каждого блока «Причина», первая строка была самым глубоким слоем и первым местом для этого блока. Например,

Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(Book.java:16)
           at com.example.myproject.Author.getBookTitles(Author.java:25)
               at com.example.myproject.Bootstrap.main(Bootstrap.java:14)

Book.java:16 был вызван Auther.java:25, который был вызван Bootstrap.java:14, Book.java:16 был основной причиной. Здесь прикрепите диаграмму сортировки стека следов в хронологическом порядке.

Существует еще одна функция stacktrace, предлагаемая семейством Throwable - возможность управлять информацией о трассировке стека.

Стандартное поведение:

package test.stack.trace;

public class SomeClass {

    public void methodA() {
        methodB();
    }

    public void methodB() {
        methodC();
    }

    public void methodC() {
        throw new RuntimeException();
    }

    public static void main(String[] args) {
        new SomeClass().methodA();
    }
}

Трассировка стека:

Exception in thread "main" java.lang.RuntimeException
    at test.stack.trace.SomeClass.methodC(SomeClass.java:18)
    at test.stack.trace.SomeClass.methodB(SomeClass.java:13)
    at test.stack.trace.SomeClass.methodA(SomeClass.java:9)
    at test.stack.trace.SomeClass.main(SomeClass.java:27)

Манипулированная трассировка стека:

package test.stack.trace;

public class SomeClass {

    ...

    public void methodC() {
        RuntimeException e = new RuntimeException();
        e.setStackTrace(new StackTraceElement[]{
                new StackTraceElement("OtherClass", "methodX", "String.java", 99),
                new StackTraceElement("OtherClass", "methodY", "String.java", 55)
        });
        throw e;
    }

    public static void main(String[] args) {
        new SomeClass().methodA();
    }
}

Трассировка стека:

Exception in thread "main" java.lang.RuntimeException
    at OtherClass.methodX(String.java:99)
    at OtherClass.methodY(String.java:55)

Другие сообщения описывают, что такое трассировка стека, но с ней все еще сложно работать.

Если вы получаете трассировку стека и хотите проследить причину исключения, хорошая начальная точка понимая, что использовать Java Stack Trace Console в Eclipse. Если вы используете другую среду IDE, может быть аналогичная функция, но этот ответ касается Eclipse.

Во-первых, убедитесь, что все ваши источники Java доступны в проекте Eclipse.

Затем в перспективе Java щелкните вкладку Console (обычно внизу). Если вид консоли не отображается, перейдите в пункт меню Окно -> Показать вид и выберите Консоль .

Затем в окне консоли нажмите на следующей кнопке (справа)

[/g8]

, а затем выберите Java Stack Trace Console из раскрывающегося списка.

Вставьте трассировку стека в консоль. Затем он предоставит список ссылок в ваш исходный код и любой другой исходный код.

Это то, что вы можете увидеть (изображение из документации Eclipse):

[/g9]

Самым последним вызовом метода будет верхняя вершина стека, которая является верхней строкой (исключая текст сообщения). Спуск по стопе идет назад во времени. Вторая строка - это метод, который вызывает первую строку и т. Д.

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

Чтобы добавить к тому, что упомянул Роб. Настройка точек останова в вашем приложении позволяет поэтапно обрабатывать стек. Это позволяет разработчику использовать отладчик, чтобы увидеть, в какой точной точке метод делает что-то непредвиденное.

Так как Rob использовал NullPointerException (NPE), чтобы проиллюстрировать что-то общее, мы можем помочь удалите эту проблему следующим образом:

, если у нас есть метод, который принимает такие параметры, как: void (String firstName)

. В нашем коде мы хотели бы оценить, что firstName содержит значение, мы сделали бы это так: if(firstName == null || firstName.equals("")) return;

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

if(dog == null || dog.firstName == null) return;

Выше был правильный порядок проверки нулей, мы начинаем с базового объекта , собака в этом случае, а затем начните спускаться по дереву возможностей, чтобы убедиться, что все будет действовать до обработки. Если бы порядок был отменен, NPE потенциально может быть выброшен, и наша программа потерпит крах.