Какой хороший подход к написанию обработки ошибок?

Question

Я ненавижу писать код ошибки. Я думаю, у меня нет хорошего подхода к этому:

• Ты пишешь весь свой "функционал" сначала код, затем вернитесь и добавьте обработка ошибок или наоборот?
• Как глупо вы полагаете, что ваши пользователи есть
• Как гранулированно ты делаешь исключение?

У кого-нибудь есть совет мудреца, чтобы сделать это проще?

Большое количество отличных ответов, ребята, спасибо. На самом деле я получил больше ответов о работе с пользователем, чем думал. На самом деле меня больше интересует обработка ошибок на стороне сервера, работа со сбоями соединения с базой данных, потенциальное влияние на интерфейс и т.д.

Answer 1

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

Относитесь к ним с уважением и не думайте, что они знают все о вашей системе, вы здесь, чтобы помочь им .

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

Обычно я не выкидываю столько исключений.

Answer 2

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

Затем напишите свой код обработки ошибок соответственно.

Answer 3

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

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

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

Answer 4

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

Главный пример, у меня была форма с полем электронной почты. Мы не сразу использовали эти данные, поэтому не проверяли их. Результат: около 1% пользователей указали свой домашний адрес. Поле было помечено как «Адрес электронной почты». Очевидно, пользователи просто читали второе слово и игнорировали первое.

Исправление было в том, чтобы изменить метку, чтобы просто сказать «Электронная почта», а затем проверить ввод. Для пинка мы пошли дальше и записали, что пользователи первоначально вводили в это поле, просто чтобы посмотреть, помогла ли смена метки. Это сделал.

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

Answer 5

Кто-то уже упоминал защитное программирование . Несколько мыслей с точки зрения пользовательского опыта.

• Если введенные пользователем данные неверны, либо (а) исправьте их, если вы достаточно уверены, что знаете, что они имели в виду, либо (б) отобразите сообщение в строке , в котором указано, какие корректирующие действия ему следует предпринять брать.
• Избегайте сообщений типа «КОД ОШИБКИ ФАТАЛЬНОЙ СИСТЕМЫ 02382981». Пользователи (а) не знают, что это значит, даже если вы это делаете, и (б) их пугают и откладывают, видя подобные вещи.
• Избегайте всплывающих сообщений о каждой - офигенной - возможной - ошибке, с которой вы можете столкнуться. Вы не должны нарушать пользовательский поток, если вам абсолютно не нужно, чтобы они решали проблему, прежде чем они смогут сделать что-либо еще.
• Журнал, журнал, журнал. Когда вы выводите сообщение об ошибке пользователю, поместите соответствующую информацию, которая может помочь вам в отладке, либо (а) в файл журнала, либо (б) в базу данных, в зависимости от типа создаваемого приложения. Это облегчит поиск информации об ошибке, не заставляя пользователя плакать.

Как только вы определите, что ваши пользователи должны и не должны делать, вы сможете эффективно писать код обработки ошибок. Вы можете сделать это проще с помощью вспомогательных методов / классов.

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

Answer 6

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

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

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

Answer 7

У меня есть два слова для вас : Защитное кодирование