Конец трассировка стека из предыдущего расположения где возникло исключение whatsapp
Иногда, когда я запускаю свое приложение, оно выдает мне ошибку, которая выглядит следующим образом:
Люди называют это «следом стека». Что такое трассировка стека? Что он может сказать мне об ошибке, которая происходит в моей программе?
Об этом вопросе - довольно часто я вижу вопрос, когда начинающий программист «получает ошибку», и они просто вставляют свою трассировку стека и некоторый случайный блок кода, не понимая, что такое трассировка стека или как они могут ее использовать. Этот вопрос предназначен для начинающих программистов, которым может понадобиться помощь в понимании значения трассировки стека.
Кроме того, если строка трассировки стека не содержит имя файла и номер строки, класс для этой строки не был скомпилирован с отладочной информацией.Проще говоря, трассировка стека - это список вызовов методов, которые приложение находилось в середине, когда было сгенерировано исключение.
Простой пример
С помощью примера, приведенного в вопросе, мы можем точно определить, где было выброшено исключение в приложении. Давайте посмотрим на трассировку стека:
Это очень простая трассировка стека. Если мы начнем с начала списка «at . », мы можем сказать, где произошла наша ошибка. Мы ищем самый верхний вызов метода, который является частью нашего приложения. В данном случае это:
Чтобы отладить это, мы можем открыть Book.java и посмотреть на строку 16 , которая:
Это будет означать, что что-то (вероятно title ) находится null в приведенном выше коде.
Пример с цепочкой исключений
Иногда приложения перехватывают исключение и повторно генерируют его как причину другого исключения. Это обычно выглядит так:
Это может дать вам трассировку стека, которая выглядит следующим образом:
То, что отличается от этого, это «Причины». Иногда исключения будут иметь несколько разделов «Причины». Для них обычно требуется найти «основную причину», которая будет одной из самых низких «причинных» секций в трассировке стека. В нашем случае это:
Опять же , с этим исключением мы хотели бы посмотреть на линию 22 из , Book.java чтобы увидеть , что может привести NullPointerException здесь.
Более сложный пример с библиотечным кодом
Обычно трассировки стека намного сложнее, чем два приведенных выше примера. Вот пример (он длинный, но демонстрирует несколько уровней связанных исключений):
В этом примере намного больше. Что нас больше всего беспокоит, так это поиск методов, взятых из нашего кода , которые будут в com.example.myproject пакете. Из второго примера (выше), мы сначала хотели бы найти первопричину, а именно:
Однако все вызовы методов в соответствии с этим являются библиотечным кодом. Итак, мы перейдем к «Причины» над ним и поищем первый вызов метода, происходящий из нашего кода, а именно:
Как и в предыдущих примерах, мы должны смотреть MyEntityService.java онлайн 59 , потому что именно здесь возникла эта ошибка (эта ошибка немного очевидна, что пошло не так, поскольку SQLException сообщает об ошибке, но мы ищем процедуру отладки).
@RobHruska - Очень хорошо объяснил. +1. Знаете ли вы какие-либо парсеры, которые принимают трассировку исключений в виде строки и предоставляют полезные методы для анализа трассировки стека? - как getLastCausedBy () или getCausedByForMyAppCode ("com.example.myproject") @AndyDufresne - я не сталкивался ни с кем, но опять же, я действительно не смотрел, либо.Я публикую этот ответ, поэтому самый верхний ответ (при сортировке по активности) не является просто ошибочным.
Что такое Stacktrace?
Stacktrace - очень полезный инструмент отладки. Он показывает стек вызовов (т. Е. Стек функций, которые были вызваны до этой точки) в момент возникновения неперехваченного исключения (или в момент, когда трассировка стека была сгенерирована вручную). Это очень полезно, поскольку показывает не только, где произошла ошибка, но и то, как программа оказалась в этом месте кода. Это приводит к следующему вопросу:
Что такое исключение?
Исключением является то, что среда выполнения использует, чтобы сообщить вам, что произошла ошибка. Популярные примеры: NullPointerException, IndexOutOfBoundsException или ArithmeticException. Каждый из них вызывается, когда вы пытаетесь сделать что-то, что невозможно. Например, исключение NullPointerException будет выдано при попытке разыменования объекта Null:
Как я должен иметь дело со стеками / исключениями?
Сначала выясните, что вызывает исключение. Попробуйте поискать название исключения, чтобы выяснить причину этого исключения. В большинстве случаев это будет вызвано неправильным кодом. В приведенных выше примерах все исключения вызваны неправильным кодом. Так что для примера NullPointerException вы можете убедиться, что a он никогда не будет нулевым в то время. Вы можете, например, инициализировать a или включить проверку, подобную этой:
Таким образом, оскорбительная строка не выполняется, если a==null . То же самое касается других примеров.
Иногда вы не можете быть уверены, что не получите исключения. Например, если вы используете сетевое соединение в своей программе, вы не можете остановить компьютер от потери его интернет-соединения (например, вы не можете запретить пользователю отключать сетевое соединение компьютера). В этом случае сетевая библиотека, вероятно, выдаст исключение. Теперь вы должны поймать исключение и обработать его. Это означает, что в примере с сетевым подключением вы должны попытаться повторно открыть подключение или уведомить пользователя или что-то в этом роде. Кроме того, всякий раз, когда вы используете catch, всегда перехватываете только исключение, которое вы хотите перехватить, не используйте такие широкие операторы catch, как catch (Exception e) что бы поймать все исключения. Это очень важно, потому что в противном случае вы можете случайно поймать не то исключение и отреагировать неправильно.
Почему я не должен использовать catch (Exception e) ?
Давайте используем небольшой пример, чтобы показать, почему вы не должны просто перехватывать все исключения:
Этот код пытается отловить ArithmeticException причину, вызванную возможным делением, на 0. Но он также отлавливает возможное NullPointerException , которое выбрасывается, если a или b есть null . Это означает, что вы можете получить, NullPointerException но вы будете относиться к нему как к ArithmeticException и, вероятно, будете поступать неправильно. В лучшем случае вы все еще скучаете по тому, что было исключение NullPointerException. Такие вещи делают отладку намного сложнее, так что не делайте этого.
Читайте также: