Отладка ошибок времени выполнения в выпущенном приложении flex

Question

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

Интересно, есть ли у кого-нибудь советы о том, как подойти к этому. Все, что я могу придумать - это записать как можно больше событий в некотором буфере, а затем вывести их на сервер, когда произойдет сбой. Я реализовал это, и это нормально, но, к сожалению, добавление журналов повсеместно не кажется очень практичным, если ваша база кода достаточно обширна. Но, может быть, есть загвоздка в том, чтобы регистрировать все виды вещей каким-то простым способом, о котором я не подумал - своего рода централизованным слушателем? Или, может быть, какой-то другой подход?

Приму любой совет (хотя в идеале следует пропустить «Вы должны протестировать свое приложение, прежде чем выпустить его»?).

спасибо!

Answer 1

К сожалению, на данный момент мало что можно сделать.Разумеется, очевидным местом для начала будет попытка заставить пользователя запустить программу на отладочной версии Flash Player.Но если вы не можете, и вам нужно найти способ «встроить» обнаружение ошибок во время выполнения «всеобъемлющим» способом, есть только два немедленных способа устранения:

1. Вставка сообщений журнала по умолчанию в критических точках вашего приложения.Это должно быть на более высоком уровне абстракции, возможно, при создании или удалении модулей или при запуске и завершении сложных задач.В идеале, протоколирование также должно быть настраиваемым, чтобы вы могли включать или выключать подробный вывод, когда вам это нужно, например, изменяя файл конфигурации или устанавливая переменную среды во время компиляции - отладочный код может немного замедлить ваше приложение, ивам не нужно добавлять и удалять отдельные операторы трассировки каждый раз, когда вы получаете ошибку.Если вы продвинутый разработчик ActionScript, вам может даже понадобиться найти способ реализовать ведение журнала с помощью метаданных и / или пользовательских пространств имен - это гораздо более чистый подход.

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

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

Вот несколько простых вещей, которые вы можете сделать, чтобы облегчить себе жизнь в будущем:

Самая большая ошибка, которую обычно делают люди, - это не допустить, чтобы ошибки возникали в первую очередь : Если, например, у вас есть много null -проверок в коде приложения:

if (myVar != null) doMyStuff(); // or
if (myVar == null) return;

, это обычно используется для предотвращения появления ужасной ошибки # 1009, это относительно эффективно, и вНа первый взгляд это быстрее, чем использование блока try...catch.Но это также затеняет корень проблемы или даже оставит ее незамеченной: ваша ошибка может появиться позже, когда что-то еще должно было быть инициализировано в doMyStuff(), или может бытьместа, где вы просто забыли проверить.

Лучшая стратегия, позволяющая избежать ошибок:

• Никогда не возвращать и не присваивать недопустимые значения (например, donне позволяйте вашим функциям возвращать null, присваивать начальные значения всем переменным и т. д.)

• Реализация try...catch блоков в критических точках в приложении (всякий раз, когда что-то может пойти не так, по существу).Затем они отправляют подробные сообщения журнала при обнаружении ошибок, и поэтому вы можете легко определить причину, не прибегая к длительным сеансам отладки.

• Создание самопроверяющихся объектов.Мне нравится иметь метод verify(), который вызывается до того, как объект инициализирован или добавлен на сцену, проверяет все необходимые зависимости - и выдает InstantiationException, если что-то отсутствует или имеет неправильное значение.

Answer 2

Я следую ответу weltraumpirat и добавляю еще несколько «лучших практик».Реализовать другой регистратор, который просто содержит массив строк.Вы должны использовать логирование в большинстве частей вашего приложения.Таким образом, вы можете получить что-то вроде искусственной трассировки стека.Сделайте уровень журнала отладчика в памяти управляемым через веб-сервер, загрузив конфигурацию xml или что-то еще при запуске.Добавьте глобальные обработчики ошибок и ошибок и объедините их в одной точке.Там строят объект значения ошибки с т.е.возможности игрока, искусные.трассировка стека, орг.сообщение об ошибке и т. д. и попробуйте отправить его через удаленный вызов на сервер.

Answer 3

То, что я однажды попробовал для простого проекта: я написал сценарий, который анализировал исходный код и вставлял некоторый код, который при входе в функцию помещал бы имя функции и аргументы в стек, а при выходе из нее появлялось бы имяи аргументы из стека.

Существуют определенные ситуации, когда этого будет недостаточно или очень трудно сделать, хотя:

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

2. Я всегда пишу свой код таким образом, чтобы последняя и единственная последняя строка функции возвращалась из функции, поэтому мне легко найти все места, где я должен извлечь элемент из стека, но вам может потребоваться большесложный алгоритм.

3. AS3 имеет чрезвычайно запутанную грамматику, так что написание 100% правильного препроцессора является очень утомительной задачей.Я согласился с тем, что препроцессор может выдавать ошибочный код при использовании с E4X, и в этом случае пришлось бы исправлять его вручную.