Что должно быть включено в современную стратегию обработки ошибок и исключений?

Ответ 1

Здесь так много возможных ответов, но я возьму на себя треск.

Какие проблемы должен учитывать разработчик приложения при разработке стратегии обработки ошибок и исключений?

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

Как стратегия будет различаться в зависимости от типа программного обеспечения (COTS, собственное бизнес-приложение, консультационные услуги, игра, веб-приложение, встроенное и т.д.)? Важен ли тип программного обеспечения?

• Для типа рабочего стола или встроенных приложений запись информации об окружающей среде (версия os, аппаратное обеспечение, другие запущенные приложения и т.д.) может быть очень полезна при расследовании отчетов об ошибках.
• Для корпоративных приложений и веб-приложений очень полезны такие вещи, как уведомления об ошибках электронной почты, обмен сообщениями SMS и интеграция с инструментами ECO (например, Tivoli).

Этические, политические и юридические вопросы?

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

Различные перспективы обработки ошибок (пользователь, разработчик, поддержка бизнеса, управление).

• С точки зрения пользователя старайтесь избегать ошибок, создавая интерфейс таким образом, чтобы им было сложно ошибаться. Не задавайте вопросов, которые пользователь, вероятно, не сможет ответить (прерывать, повторять, отказывать кому-либо?)

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

• С точки зрения поддержки бизнеса и управления они хотят знать, что делать с ошибкой (в основном в корпоративной среде) - кто несет ответственность за приложение (кто я вызываю /page/etc?), а также критичность и любые возможные побочные эффекты (например, если это пакетное задание не удается, какие бизнес-процессы повлияют?). Письменная документация - ваш друг здесь.

Ответ 2

Я исхожу из фона Java, но мой ответ также должен применяться к .Net.

Правила большого пальца:

• Настройте свой код для сбоя: Hunt and Thomas; Совет 33
• Проверьте все свои параметры с помощью библиотеки проверки параметров - это не исключительные условия. Они являются неправильным использованием (документированного) API. Пример: коллекции google Predicates
• Использовать исключения для исключительных условий: [Hunt and Thomas]; Совет 34. Исключения НЕ должны использоваться в качестве кодов возврата.
• Проверка на исключительные условия: Исключения являются постусловиями для вызовов методов. Если вы не можете попасть туда с тестом, исключение не должно быть объявлено.
• (для Java) Следуйте совет Джоша Блоха (все главы 9). Некоторые важные советы: 5а. Выбросьте исключения, соответствующие абстракции. 5б. Стремитесь к отказу атомарности. 5с. Включите информацию о сбое в подробном сообщении (или инкапсулируйте его в самом Исключении). 5d. Не игнорируйте Исключения.

Ответ 3

Я столкнулся с некоторыми из этих проблем на работе - на самом деле у меня не было возможности изучить его там. Мои мысли:

Какие проблемы должен учитывать разработчик приложения при разработке стратегии обработки ошибок и исключений?

Идеальной стратегией обработки исключений было бы полное восстановление и регистрация ошибки. Уловка-22 - если бы вы могли это сделать, разве вы не указали бы ее в коде в первую очередь? Таким образом, это не действительно "исключение" как таковое, плюс сложность реализации оказывается экспоненциальной. Другая сторона этого была бы в области автономных систем и подхода "самовосстановления программного обеспечения". Я считаю, что самая реалистичная стратегия - всегда пытаться заставить систему в постоянном состоянии (т.е. Минимальный ущерб). Вы всегда будете вынуждены компрометировать что-то - потерю или повреждение данных, потерю ресурсов, что приводит к снижению производительности и т.д.; однако, находясь в постоянном состоянии, вы увеличиваете свой шанс оставаться на работе с уменьшенной способностью, а не сталкиваться с полным отключением. Формализация согласованного состояния среди проектной команды может означать установление естественных значений по умолчанию, которые будут использоваться как состояние reset.

Как стратегия будет различаться в зависимости от типа программного обеспечения (COTS, собственное бизнес-приложение, консультационные услуги, игра, веб-приложение, встроенное и т.д.)? Важен ли тип программного обеспечения?

Я думаю, что каждый тип программного обеспечения поддается различным требованиям аудита и QoS, и это отражается в расходах, связанных с простоем и/или повреждением данных; однако общая стратегия одинаков. Благодаря встроенному алгоритму стратегия сводит к минимуму возникновение проблемы для пользователя и создает журналы. Вы можете добиться этого, перезапустив программное обеспечение тихо (т.е. reset состояние). С размещенными веб-приложениями данные сеанса от сбоя могут быть сброшены для последующего анализа, и пользователь получит новый сеанс. Для игры (особенно для таких вещей, как MMORPG) вы инвестируете средства в поддержку данных моментальных снимков, чтобы предотвратить проигрыш игроков в случае сбоя сервера. В этих реализациях также очень важны методы кластеризации серверов и отказов.

Этические, политические и юридические вопросы?

Прозрачность, вероятно, является самой важной частью обработки ошибок и исключений, которая будет осуществляться в форме ведения аудита. Конечным результатом этих проблем является демонстрация сбоя системы (если какой-либо побочный ущерб возникает) является результатом непредсказуемой цепочки событий, которые не могут быть разумно предусмотрены дизайнерами. Также важно продемонстрировать, что любые механизмы управления на месте имеют положительный эффект, уменьшая ущерб и т.д. Также важно держать пользователей в цикле перед лицом катастрофического сбоя (например, "Где мой сервер WoW?"?), но мой основной момент заключается в том, что прозрачность должна применяться к дисциплинированному аудиту в целях восстановления отказа.

Различные перспективы обработки ошибок (пользователь, разработчик, поддержка бизнеса, управление).

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

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

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

Ответ 4

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

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

Для жизненно важных пакетных процессов ничто не сравнится с проактивным уведомлением об успехе. Если сообщение "пакетное заполнение" не приходит, пользователь знает что-то, даже если обработка ошибок является fubar.

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

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

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

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

Подводя итог:

• Получить подробную информацию об ошибке к команде разработчиков надежно.

• Ошибки ловушки всегда на границах компонентов и только на границах компонентов.

• Сделать все исключения кода безопасными.

• Не позволяйте системе обработки ошибок становятся частью проблемы.

Ответ 5

Я не собираюсь выигрывать награду, но вот некоторые стратегии, которые я использовал и которые были хорошо приняты:

• Извлечение информации из подкомпонентов и сопоставление их с функциональными подразделениями помогло нашим бизнес-аналитикам и конечным пользователям лучше понять ошибки

• Назначение уровня приоритета бизнеса поможет в зависимости от домена, в котором вы работаете.

• Приложение Seperate Error Viewer помогло нам просмотреть ошибки до того, как они были отправлены, поэтому мои команды могут их исправить.

• Исключения в системном уровне лучше, если они не запутаны.

• Асинхронное ведение журнала ошибок поможет в общей стратегии и дизайне.

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

Ответ 6

<opening my mind to new concepts>

• Диаграмма текущего потока ошибок с помощью аналогового tickertape или монитора слежения за землетрясением, проверьте прогресс в течение недели и сравните его с историческими данными, данными об использовании и сравните их с заданными целями. Временный ставит длинный печатный длинный график на стенах и объединяет группу для обзора. Вы покупаете их напитки, объясняя свой вопрос, на этот раз очень конкретно, что программисты знают, для чего вам нужна стратегия. Готов поспорить, что один кофейник даст вам эффективный и удовлетворяющий стратегический ответ на ваш вопрос.

<closing my mind to new contepts>