Что такое stack trace, и как с его помощью находить ошибки при разработке приложений?
Иногда при запуске своего приложения я получаю подобную ошибку:
Мне сказали, что это называется «трассировкой стека» или «stack trace». Что такое трассировка? Какую полезную информацию об ошибке в разрабатываемой программе она содержит?
Немного по существу: довольно часто я вижу вопросы, в которых начинающие разработчики, получая ошибку, просто берут трассировки стека и какой-либо случайный фрагмент кода без понимания, что собой представляет трассировка и как с ней работать. Данный вопрос предназначен специально для начинающих разработчиков, которым может понадобиться помощь в понимании ценности трассировки стека вызовов.
Простыми словами, трассировка стека – это список методов, которые были вызваны до момента, когда в приложении произошло исключение.
Простой случай
В указанном примере мы можем точно определить, когда именно произошло исключение. Рассмотрим трассировку стека:
Это пример очень простой трассировки. Если пойти по списку строк вида «at…» с самого начала, мы можем понять, где произошла ошибка. Мы смотрим на верхний вызов функции. В нашем случае, это:
Для отладки этого фрагмента открываем Book.java и смотрим, что находится на строке 16 :
Это означает то, что в приведенном фрагменте кода какая-то переменная (вероятно, title ) имеет значение null .
Пример цепочки исключений
Иногда приложения перехватывают исключение и выбрасывают его в виде другого исключения. Обычно это выглядит так:
Трассировка в этом случае может иметь следующий вид:
В этом случае разница состоит в атрибуте «Caused by» («Чем вызвано»). Иногда исключения могут иметь несколько секций «Caused by». Обычно необходимо найти исходную причину, которой оказывается в самой последней (нижней) секции «Caused by» трассировки. В нашем случае, это:
Аналогично, при подобном исключении необходимо обратиться к строке 22 книги Book.java , чтобы узнать, что вызвало данное исключение – NullPointerException .
Еще один пугающий пример с библиотечным кодом
Как правило, трассировка имеет гораздо более сложный вид, чем в рассмотренных выше случаях. Приведу пример (длинная трассировка, демонстрирующая несколько уровней цепочек исключений):
В этом примере приведен далеко не полный стек вызовов. Что вызывает здесь наибольший интерес, так это поиск функций из нашего кода – из пакета com.example.myproject . В предыдущем примере мы сначала хотели отыскать «первопричину», а именно:
Однако все вызовы методов в данном случае относятся к библиотечному коду. Поэтому мы перейдем к предыдущей секции «Caused by» и найдем первый вызов метода из нашего кода, а именно:
Что такое трассировка стека и как ее использовать для отладки ошибок приложения?
Иногда, когда я запускаю свое приложение, я получаю ошибку, которая выглядит примерно так:
Люди называют это «трассировкой стека». Что такое трассировка стека? Что он может сказать мне об ошибке в моей программе?
По поводу этого вопроса — довольно часто я вижу, как начинающий программист "получает ошибку" и просто вставляет свою трассировку стека и какой-то случайный блок кода, не понимая, что такое трассировка стека и как они могут ее использовать. Этот вопрос предназначен в качестве справочника для начинающих программистов, которым может потребоваться помощь в понимании значения трассировки стека.
- 28 Кроме того, если строка трассировки стека не содержит имени файла и номера строки, класс для этой строки не был скомпилирован с отладочной информацией.
Проще говоря, трассировки стека — это список вызовов методов, в процессе которых приложение находилось в момент создания исключения.
Простой пример
С помощью примера, приведенного в вопросе, мы можем точно определить, где в приложении возникло исключение. Давайте посмотрим на трассировку стека:
Это очень простая трассировка стека. Если мы начнем с начала списка «в . », мы сможем сказать, где произошла наша ошибка. Мы ищем самый верхний вызов метода, который является частью нашего приложения. В данном случае это:
Чтобы отладить это, мы можем открыть Book.java и посмотрите на строку 16 , который:
Это означало бы, что что-то (возможно, title ) является null в приведенном выше коде.
Пример с цепочкой исключений
Иногда приложения перехватывают исключение и повторно генерируют его как причину другого исключения. Обычно это выглядит так:
Это может дать вам трассировку стека, которая выглядит так:
Что отличает этот, так это «Причина». Иногда исключения содержат несколько разделов «Причина». Для них обычно требуется найти «основную причину», которая будет одним из самых низких разделов «Причина» в трассировке стека. В нашем случае это:
Опять же, за этим исключением мы хотели бы посмотреть на строку 22 из Book.java чтобы увидеть, что может вызвать NullPointerException Вот.
Более устрашающий пример с библиотечным кодом
Обычно трассировки стека намного сложнее, чем два приведенных выше примера. Вот пример (он длинный, но демонстрирует несколько уровней связанных исключений):
В этом примере многое другое. Что нас больше всего беспокоит, так это поиск методов из наш код, что было бы чем угодно в com.example.myproject пакет. Во втором примере (выше) мы сначала хотели бы найти основную причину, а именно:
Однако все вызовы методов под этим кодом являются библиотечным кодом. Итак, мы перейдем к пункту «Причина» над ним и найдем первый вызов метода, исходящий из нашего кода, а именно:
Как и в предыдущих примерах, мы должны посмотреть на MyEntityService.java онлайн 59 , потому что именно здесь возникла эта ошибка (это немного очевидно, что пошло не так, поскольку SQLException сообщает об ошибке, но процедура отладки — это то, что нам нужно).
- 4 @RobHruska — Очень хорошо объяснено. +1. Знаете ли вы какие-либо парсеры, которые принимают трассировку исключения в виде строки и предоставляют полезные методы для анализа трассировки стека? — например, getLastCausedBy () или getCausedByForMyAppCode ("com.example.myproject")
- 1 @AndyDufresne — я не встречал ни одного, но, опять же, я тоже особо не смотрел.
- 1 Предлагаемое улучшение: объясните первую строку трассировки стека, которая начинается с Exception in thread ‘main’ в вашем первом примере. Я думаю, было бы особенно полезно объяснить, что эта строка часто сопровождается сообщением, например значением переменной, которое может помочь диагностировать проблему. Я сам попытался внести правку, но мне не удается уместить эти идеи в существующую структуру вашего ответа.
- 5 Также в java 1.7 добавлено «Подавлено:», в котором перечислены трассировки стека подавленных исключений перед отображением «Вызвано:» для этого исключения. Он автоматически используется конструкцией try-with-resource: docs.oracle.com/javase/specs/jls/se8/html/… и содержит исключения, если таковые возникли при закрытии ресурса (ов).
- Существует JEP openjdk.java.net/jeps/8220715, цель которого — еще больше улучшить понятность, особенно NPE, путем предоставления таких деталей, как «Невозможно записать поле 'nullInstanceField', потому что 'this.nullInstanceField' имеет значение null».
Я отправляю этот ответ, поэтому самый верхний ответ (при сортировке по активности) не является просто неправильным.
Что такое Stacktrace?
Трассировка стека — очень полезный инструмент отладки. Он показывает стек вызовов (то есть стек функций, которые были вызваны до этого момента) в момент возникновения неперехваченного исключения (или время, когда трассировка стека была сгенерирована вручную). Это очень полезно, потому что это не только показывает вам, где произошла ошибка, но и то, как программа оказалась в этом месте кода. Это приводит к следующему вопросу:
Что такое исключение?
Исключение — это то, что среда выполнения использует, чтобы сообщить вам, что произошла ошибка. Популярные примеры: NullPointerException, IndexOutOfBoundsException или ArithmeticException. Каждая из них возникает, когда вы пытаетесь сделать что-то, что невозможно. Например, NullPointerException будет выброшено, когда вы попытаетесь разыменовать Null-объект:
Что мне делать с трассировками стека / исключениями?
Сначала выясните, что вызывает исключение. Попробуйте поискать в Google название исключения, чтобы выяснить, в чем причина этого исключения. В большинстве случаев это вызвано неправильным кодом. В приведенных выше примерах все исключения вызваны неправильным кодом. Итак, для примера NullPointerException вы можете убедиться, что a в то время никогда не бывает нулевым. Вы можете, например, инициализировать a или включите проверку, подобную этой:
Таким образом, нарушающая строка не выполняется, если a==null . То же самое и с другими примерами.
Иногда вы не можете быть уверены, что не получите исключения. Например, если вы используете сетевое соединение в своей программе, вы не можете помешать компьютеру потерять подключение к Интернету (например, вы не можете запретить пользователю отключать сетевое подключение компьютера). В этом случае сетевая библиотека, вероятно, выдаст исключение. Теперь вы должны поймать исключение и справиться Это. Это означает, что в примере с сетевым подключением вы должны попытаться повторно открыть соединение или уведомить пользователя или что-то в этом роде. Кроме того, всякий раз, когда вы используете catch, всегда перехватывайте только исключение, которое хотите перехватить, не используйте общие операторы catch, такие как catch (Exception e) это поймает все исключения. Это очень важно, потому что в противном случае вы можете случайно поймать неправильное исключение и отреагировать неправильно.
Почему я не должен использовать catch (Exception e) ?
Давайте воспользуемся небольшим примером, чтобы показать, почему не следует просто перехватывать все исключения:
Этот код пытается поймать ArithmeticException вызвано возможным делением на 0. Но он также улавливает возможное NullPointerException это брошено, если a или же b находятся null . Это означает, что вы можете получить NullPointerException но вы будете рассматривать это как ArithmeticException и, вероятно, сделаете неправильный поступок. В лучшем случае вы все равно пропустите исключение NullPointerException. Подобные вещи значительно усложняют отладку, так что не делайте этого.
TL; DR
-
Выясните, в чем причина исключения, и устраните ее, чтобы исключение вообще не генерировалось.
Если 1. невозможно, перехватите конкретное исключение и обработайте его.
- Никогда не добавляйте просто try / catch и игнорируйте исключение! Не делай этого!
- Никогда не использовать catch (Exception e) , всегда перехватывайте определенные исключения. Это избавит вас от головной боли.
- 1 хорошее объяснение того, почему нам следует избегать маскировки ошибок
- 2 Я отправляю этот ответ, поэтому самый верхний ответ (при сортировке по активности) не является просто неправильным Я понятия не имею, о чем вы говорите, поскольку это, вероятно, уже изменилось. Но принятый ответ определенно интереснее;)
- 1 Насколько я знаю, тот, который я имел в виду, к настоящему времени удален. По сути, он гласил: «просто попробуйте <> catch (Exception e) <> и игнорируйте все ошибки». Принятый ответ намного старше моего, поэтому я стремился высказать немного другое мнение по этому поводу. Я не думаю, что кому-то поможет просто скопировать чей-то ответ или осветить то, что другие люди уже хорошо осветили.
- Сказать «Не ловить исключение» — это заблуждение — это только один вариант использования. Ваш пример великолепен, но как насчет того, где вы находитесь в верхней части цикла потока (внутренний запуск)? Вы должны ВСЕГДА перехватывать исключение (или, может быть, Throwable) там и регистрировать его, чтобы оно не исчезло незаметно (исключения, генерируемые при запуске, обычно не регистрируются правильно, если вы не настроили свой поток / регистратор для этого).
- 1 Я не включил этот особый случай, поскольку он имеет значение только для многопоточности. В однопоточном режиме просочившееся исключение убивает программу и явно регистрируется в журнале. Если кто-то не знает, как правильно обрабатывать исключения, он обычно еще не знает, как использовать многопоточность.
Чтобы добавить к тому, что сказал Роб. Установка точек останова в приложении позволяет выполнять пошаговую обработку стека. Это позволяет разработчику использовать отладчик, чтобы увидеть, в какой именно момент метод делает что-то непредвиденное.
Поскольку Роб использовал NullPointerException (NPE), чтобы проиллюстрировать что-то общее, мы можем помочь устранить эту проблему следующим образом:
если у нас есть метод, который принимает такие параметры, как: void (String firstName)
В нашем коде мы хотели бы оценить это firstName содержит значение, мы бы сделали это так: if(firstName == null || firstName.equals(»)) return;
Вышесказанное мешает нам использовать firstName как небезопасный параметр. Поэтому, выполняя нулевые проверки перед обработкой, мы можем помочь убедиться, что наш код будет работать правильно. Чтобы расширить пример, в котором используется объект с методами, мы можем посмотреть здесь:
if(dog == null || dog.firstName == null) return;
Выше приведен правильный порядок проверки на нули, мы начинаем с базового объекта, в данном случае dog, а затем начинаем спускаться по дереву возможностей, чтобы убедиться, что все правильно перед обработкой. Если бы порядок был изменен, NPE потенциально мог бы быть брошен, и наша программа вылетела бы.
- Согласовано. Этот подход можно использовать, чтобы узнать, какая ссылка в заявлении null когда NullPointerException рассматривается, например.
- 16 При работе со String, если вы хотите использовать метод equals, я думаю, что лучше использовать константу в левой части сравнения, например: Вместо: if (firstName == null || firstName.equals (" ")) возвращение; Я всегда использую: if ((""). Equals (firstName)) Это предотвращает исключение Nullpointer
Есть еще одна функция stacktrace, предлагаемая семейством Throwable — возможность манипулировать информация трассировки стека.
Стандартное поведение:
Управляемая трассировка стека:
- 2 Не знаю, как я к этому отношусь . учитывая характер потока, я бы посоветовал новым разработчикам не определять собственную трассировку стека.
Чтобы понять имя: Трассировка стека — это список исключений (или вы можете сказать список «Причина по»), от самого поверхностного исключения (например, исключения уровня обслуживания) до самого глубокого (например, исключения базы данных). Точно так же, как причина, по которой мы называем это «стеком», заключается в том, что стек первым пришел последним (FILO), самое глубокое исключение произошло в самом начале, затем была сгенерирована цепочка исключений, серия последствий, поверхностное исключение было последним. одно произошло вовремя, но мы видим это в первую очередь.
Ключ 1: Здесь необходимо понять сложную и важную вещь: самая глубокая причина может не быть «основной причиной», потому что, если вы напишете какой-то «плохой код», он может вызвать какое-то исключение внизу, которое глубже, чем его уровень. Например, неправильный sql-запрос может вызвать сброс соединения SQLServerException в нижней части вместо синтаксической ошибки, которая может быть только в середине стека.
-> Найдите основную причину, посередине — это ваша работа.
Ключ 2: Еще одна сложная, но важная вещь — внутри каждого блока «Причина по», первая строка была самым глубоким слоем и занимала первое место для этого блока. Например,
Book.java:16 был вызван Auther.java:25, который был вызван Bootstrap.java:14, Book.java:16 был основной причиной. Здесь прикрепите диаграмму, отсортируйте стек трассировки в хронологическом порядке.
Чтобы добавить к другим примерам, есть внутренние (вложенные) классы которые появляются с $ подписать. Например:
Результатом будет эта трассировка стека:
В других сообщениях описывается, что такое трассировка стека, но с ней все еще может быть сложно работать.
Если вы получили трассировку стека и хотите отследить причину исключения, хорошей отправной точкой для понимания этого будет использование Консоль Java Stack Trace в Затмение. Если вы используете другую IDE, может быть аналогичная функция, но этот ответ касается Eclipse.
Во-первых, убедитесь, что все ваши источники Java доступны в проекте Eclipse.
Тогда в Ява перспективы, нажмите на Приставка вкладка (обычно внизу). Если представление консоли не отображается, перейдите к пункту меню Окно -> Показать вид и выберите Приставка.
Затем в окне консоли нажмите следующую кнопку (справа)
а затем выберите Консоль Java Stack Trace из раскрывающегося списка.
Вставьте трассировку стека в консоль. Затем он предоставит список ссылок на ваш исходный код и любой другой доступный исходный код.
Вот что вы можете увидеть (изображение из документации Eclipse):
Самый последний сделанный вызов метода будет Топ стека, которая является верхней строкой (исключая текст сообщения). Спуск по стеку уходит в прошлое. Вторая строка — это метод, вызывающий первую строку и т. Д.
Если вы используете программное обеспечение с открытым исходным кодом, вам может потребоваться загрузить и прикрепить к своему проекту источники, если вы хотите изучить. Загрузите исходные jar-файлы, в своем проекте откройте Ссылки на библиотеки папку, чтобы найти банку для вашего модуля с открытым исходным кодом (тот, который содержит файлы классов), затем щелкните правой кнопкой мыши, выберите Свойства и прикрепите исходную банку.
Что такое трассировка стека и как я могу использовать ее для отладки ошибок моего приложения?
Иногда, когда я запускаю свое приложение, я получаю ошибку, которая выглядит примерно так:
Люди называют это «трассировкой стека». Что такое трассировка стека? Что она может сказать мне об ошибке в моей программе?
По поводу этого вопроса — довольно часто я вижу, как начинающий программист «получает ошибку» и просто вставляет свою трассировку стека и какой-то случайный блок кода, не понимая, что такое трассировка стека и как они могут используй это. Этот вопрос предназначен для начинающих программистов, которым может потребоваться помощь в понимании значения трассировки стека.
7 ответов
Проще говоря, трассировка стека — это список вызовов методов, которые приложение выполняло при возникновении исключения.
Простой пример
С помощью примера, приведенного в вопросе, мы можем точно определить, где в приложении возникло исключение. Посмотрим на трассировку стека:
Это очень простая трассировка стека. Если мы начнем с начала списка «в . », мы сможем сказать, где произошла наша ошибка. Мы ищем вызов самого верхнего метода, который является частью нашего приложения. В данном случае это:
Чтобы отладить это, мы можем открыть Book.java и посмотреть на строку 16 , которая:
Это будет означать, что что-то (вероятно, title ) есть null в приведенном выше коде.
Пример с цепочкой исключений
Иногда приложения перехватывают исключение и повторно генерируют его как причину другого исключения. Обычно это выглядит так:
Это может дать вам трассировку стека, которая выглядит так:
Что отличает этот, так это «Вызвано». Иногда исключения содержат несколько разделов «Причина». Для них обычно требуется найти «основную причину», которая будет одним из самых низких разделов «Причина» в трассировке стека. В нашем случае это:
Опять же, с этим исключением мы хотели бы взглянуть на строку 22 из Book.java , чтобы увидеть, что может вызвать здесь NullPointerException .
Более сложный пример с библиотечным кодом
Обычно трассировки стека намного сложнее, чем два приведенных выше примера. Вот пример (он длинный, но демонстрирует несколько уровней связанных исключений):
В этом примере многое другое. Что нас больше всего беспокоит, так это поиск методов, взятых из нашего кода , то есть чего угодно в пакете com.example.myproject . Во втором примере (выше) мы сначала хотели бы найти основную причину, а именно:
Однако все вызовы методов под этим кодом являются библиотечным кодом. Итак, мы перейдем к пункту «Причина» над ним и найдем первый вызов метода, исходящий из нашего кода, а именно:
Как и в предыдущих примерах, мы должны посмотреть на MyEntityService.java в строке 59 , потому что именно здесь возникла эта ошибка (это немного очевидно, что пошло не так, поскольку SQLException сообщает об ошибке, но процедура отладки что мы ищем).
Что такое Stacktrace?
Трассировка стека — очень полезный инструмент отладки. Он показывает стек вызовов (то есть стек функций, которые были вызваны до этого момента) в момент возникновения неперехваченного исключения (или время, когда трассировка стека была сгенерирована вручную). Это очень полезно, потому что показывает не только, где произошла ошибка, но и то, как программа оказалась в этом месте кода. Это приводит к следующему вопросу:
Что такое исключение?
Исключение — это то, что среда выполнения использует, чтобы сообщить вам, что произошла ошибка. Популярные примеры — NullPointerException, IndexOutOfBoundsException или ArithmeticException. Каждая из них возникает, когда вы пытаетесь сделать что-то, что невозможно. Например, при попытке разыменовать объект Null будет выброшено исключение NullPointerException:
Что делать с трассировками стека / исключениями?
Сначала выясните, что вызывает исключение. Попробуйте поискать в Google имя исключения, чтобы выяснить, в чем причина этого исключения. В большинстве случаев это вызвано неправильным кодом. В приведенных выше примерах все исключения вызваны неправильным кодом. Итак, для примера NullPointerException вы можете убедиться, что a никогда не имеет значения NULL в это время. Вы можете, например, инициализировать a или включить проверку, подобную этой:
Таким образом, нарушающая строка не выполняется, если a==null . То же самое и с другими примерами.
Иногда вы не можете быть уверены, что не получите исключения. Например, если вы используете сетевое соединение в своей программе, вы не можете помешать компьютеру потерять подключение к Интернету (например, вы не можете запретить пользователю отключать сетевое подключение компьютера). В этом случае сетевая библиотека, вероятно, выдаст исключение. Теперь вы должны перехватить исключение и обработать его. Это означает, что в примере с сетевым подключением вы должны попытаться повторно открыть соединение или уведомить пользователя или что-то в этом роде. Кроме того, всякий раз, когда вы используете catch, всегда перехватывайте только то исключение, которое хотите перехватить, не используйте общие операторы перехвата, такие как catch (Exception e) , которые перехватывали бы все исключения. Это очень важно, потому что в противном случае вы можете случайно поймать неправильное исключение и отреагировать неправильно.
Почему мне не следует использовать catch (Exception e) ?
Давайте воспользуемся небольшим примером, чтобы показать, почему не следует просто перехватывать все исключения:
Этот код пытается поймать ArithmeticException , вызванное возможным делением на 0. Но он также улавливает возможное NullPointerException , которое выбрасывается, если a или b являются null . Это означает, что вы можете получить NullPointerException , но вы будете рассматривать его как ArithmeticException и, вероятно, сделаете неправильный шаг. В лучшем случае вы все равно пропустите исключение NullPointerException. Подобные вещи значительно усложняют отладку, так что не делайте этого.
TL; DR
- Выясните, в чем причина исключения, и исправьте ее, чтобы исключение вообще не генерировалось.
- Если 1. невозможно, перехватите конкретное исключение и обработайте его.
- Никогда не добавляйте просто try / catch и игнорируйте исключение! Не делай этого!
- Никогда не используйте catch (Exception e) , всегда перехватывайте определенные исключения. Это избавит вас от головной боли.
Чтобы добавить к тому, что сказал Роб. Установка точек останова в вашем приложении позволяет выполнять пошаговую обработку стека. Это позволяет разработчику использовать отладчик, чтобы увидеть, в какой именно момент метод делает что-то неожиданное.
Поскольку Роб использовал NullPointerException (NPE), чтобы проиллюстрировать что-то общее, мы можем помочь устранить эту проблему следующим образом:
Если у нас есть метод, который принимает такие параметры, как: void (String firstName)
В нашем коде мы хотели бы оценить, что firstName содержит значение, мы бы сделали это так: if(firstName == null || firstName.equals(«»)) return;
Вышесказанное не позволяет нам использовать firstName в качестве небезопасного параметра. Поэтому, выполняя нулевые проверки перед обработкой, мы можем помочь убедиться, что наш код будет работать правильно. Чтобы расширить пример, в котором используется объект с методами, мы можем посмотреть здесь:
if(dog == null || dog.firstName == null) return;
Приведенный выше порядок является правильным для проверки наличия нулей, мы начинаем с базового объекта, в данном случае dog, а затем начинаем спускаться по дереву возможностей, чтобы убедиться, что все допустимо перед обработкой. Если бы порядок был изменен, NPE потенциально мог бы быть брошен, и наша программа вылетела бы.
Чтобы понять название : трассировка стека — это список исключений (или вы можете сказать список «Причина по»), от самого поверхностного исключения (например, исключение уровня сервиса) до самого глубокого ( например, исключение базы данных). Точно так же, как причина, по которой мы называем это «стеком», заключается в том, что стек является первым зашел последним (FILO), самое глубокое исключение произошло в самом начале, затем была сгенерирована цепочка исключений, серия последствий, поверхностное исключение было последним. одно произошло вовремя, но мы видим это в первую очередь.
Ключ 1 . Здесь необходимо понять сложную и важную вещь: самая глубокая причина может не быть «основной причиной», потому что, если вы напишете какой-то «плохой код», это может вызвать какое-то исключение ниже который глубже его слоя. Например, неверный sql-запрос может вызвать сброс соединения SQLServerException в нижней части вместо синтаксической ошибки, которая может быть только в середине стека.
-> Найдите основную причину в вашей работе.
Ключ 2 . Еще одна сложная, но важная вещь — внутри каждого блока «Причина по», первая строка была самым глубоким слоем и занимала первое место в этом блоке. Например,
Book.java:16 был вызван Auther.java:25, который был вызван Bootstrap.java:14, Book.java:16 был основной причиной. Здесь прикрепите диаграмму, отсортируйте стек трассировки в хронологическом порядке.
Есть еще одна функция трассировки стека, предлагаемая семейством Throwable — возможность манипулировать информацией трассировки стека.
Стандартное поведение:
Обработка трассировки стека:
Чтобы добавить к другим примерам, есть внутренние (вложенные) классы , которые отмечены знаком $ . Например:
Результатом будет эта трассировка стека:
В других сообщениях описывается, что такое трассировка стека, но с ней все равно сложно работать.
Если вы получили трассировку стека и хотите отследить причину исключения, хорошей отправной точкой для понимания этого является использование Java Stack Trace Console в Eclipse . Если вы используете другую IDE, может быть аналогичная функция, но этот ответ касается Eclipse.
Во-первых, убедитесь, что все ваши источники Java доступны в проекте Eclipse.
Затем в перспективе Java щелкните вкладку Консоль (обычно внизу). Если представление консоли не отображается, перейдите к пункту меню Окно -> Показать представление и выберите Консоль .
Затем в окне консоли нажмите следующую кнопку (справа)
А затем в раскрывающемся списке выберите Консоль трассировки стека Java .
Вставьте трассировку стека в консоль. Затем он предоставит список ссылок на ваш исходный код и любой другой доступный исходный код.
Вот что вы можете увидеть (изображение из документации Eclipse):
Самый последний сделанный вызов метода будет вершиной стека, то есть верхней строкой (за исключением текста сообщения). Спуск по стеку уходит в прошлое. Вторая строка — это метод, вызывающий первую строку и т. Д.
Если вы используете программное обеспечение с открытым исходным кодом, вам может потребоваться загрузить и прикрепить к своему проекту источники, если вы хотите изучить. Загрузите исходные jar-файлы в своем проекте, откройте папку Referenced Libraries , чтобы найти jar-файл для вашего модуля с открытым исходным кодом (тот, который содержит файлы классов), затем щелкните правой кнопкой мыши, выберите Properties и прикрепите исходный jar.