В какой степени код должен пытаться объяснить фатальные исключения?

Question

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

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

Мой вопрос: в какой степени программное обеспечение должно отвечать за попытку объяснить значение фатальной ошибки? В целом, какую компетенцию / знания вы можете полагать на администраторов программного обеспечения, и сколько вы должны включать информацию по устранению неполадок и возможные шаги по устранению при регистрации фатальных ошибок? Конечно, если есть что-то уникальное для контекста времени выполнения, это обязательно должно быть зарегистрировано; но давайте предположим, что вашему программному обеспечению необходимо связаться с Active Directory через LDAP и получить сообщение об ошибке "[LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece]". Разумно ли предположить, что сопровождающие смогут гуглить код ошибки и выяснить, что это означает , или если программное обеспечение попытается проанализировать код ошибки и записать, что это вызвано неправильным DN пользователя в конфиге LDAP?

Я не знаю, есть ли определенный наилучший ответ на этот вопрос, поэтому мне очень хотелось бы услышать различные мнения.

Answer 1

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

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

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

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

Просто мой 2с

Answer 2

Ответ, как и на все широкие вопросы: «это зависит».

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

Одна вещь, которую вы сказали, касается меня:

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

Если это действительно фатальная ошибка, сервер не должен работать, и поэтому любой входящий запрос должен завершаться сбоем без каких-либо предупреждений или объяснений.

Answer 3

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

Answer 4

Я полагаю, это зависит от того, сколько у вас есть времени, прежде чем доставить программное обеспечение своим клиентам.

Да, было бы неплохо разобрать ошибку и дать более четкое сообщение, но в наше время Google не всегда очень далеко.

Так что, если у вас нет времени на создание кода для разбора ошибок, я бы оставил их как есть.

Answer 5

См. https://meta.stackexchange.com/questions/3122/formatting-sandbox

Answer 6

Я считаю, что все ошибки и исключения должны иметь два аспекта:

1) Достаточно информации в ошибке, чтобы помочь отладить проблему. Stacktrace, имя класса / метода, тип исключения и т. Д. Попадают в эту категорию.

2) Понятное для человека сообщение, идеально понятное, чтобы, например, команда Ops или инженер Sysadmins знали, кому позвонить или переслать это сообщение об ошибке. Как правило, он имеет вид «такой-то и сбой модуля» или «сбой сетевого вызова» и т. Д. Что-то, что будет вам ближе, объясняя проблему клиенту, на нетехническом языке.

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

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

Answer 7

Я думаю, это зависит от того, кто использует приложение.

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

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

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

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

Answer 8

ИМХО, вы никогда не сможете предоставить слишком много информации в этом случае.

В реальном мире все сводится к анализу затрат и выгод. Какое влияние эта ошибка оказывает на вас, на ваше приложение, на ваш бизнес и т. Д. Сколько времени стоит потратить на это.

В критически важном для бизнеса приложении применяется мой первый пункт. Все остальное - скользящая шкала.