Попробуйте вспомнить, какие оригинальные и необычные сообщения об ошибках вам выдавали многочисленные программы и приложения, которыми вы пользуетесь. Наверняка у каждого из вас найдётся пара забавных примеров таких сообщений. В моём личном рейтинге на данный момент безусловный лидер — «Метод вернул что-то не то». Если существует шкала информативности сообщений, то приведённый пример по этой шкале стремится к нулю.
Здесь система, по сути, сообщает нам, что произошла ошибка. Больше никакой информации из этого текста мы не получим. Разве что узнаем, что где-то в недрах самой системы существует какой-то метод, который что-то не то вернул. Ценность этого знания для обычного пользователя нулевая.
Можно предположить, что этот текст — артефакт, оставшийся от процесса тестирования очередной функциональности. Некий флаг, оставленный разработчиком на этапе альфа-тестирования. Для программиста он явно имел какой-то смысл, но для пользователя — совершенно бесполезен.
К сожалению, подобные сообщения в наших программах и системах — не редкость. Разработчики оставляют в коде технические сообщения, а иногда просто ленятся написать хорошее информативное описание ошибки. А ведь такой текст не только помог бы пользователю в работе, но и снизил бы количество обращений в службу поддержки. Если пользователю внятно объяснить, что он сделал не так и как сделать правильно, то он наверняка справится с проблемой самостоятельно.
Каким же должно быть идеальное сообщение об ошибке?
5 основных правил
В книге Сьюзан Уэйншенк «100 главных принципов дизайна» приведены основные правила написания информативного и полезного сообщения об ошибке:
Расскажите пользователю, что он сделал.
Объясните проблему.
Объясните, как исправить ошибку.
Используйте активный, а не пассивный залог.
Приведите пример.
В книге есть пример того, как не надо писать сообщения об ошибке:
#402: до того как счёт может быть оплачен, необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
После варианта «Метод вернул что-то не то» даже такое сообщение может показаться довольно информативным. Однако в нём есть что улучшить. Но для начала давайте в порядке эксперимента попробуем его ухудшить — разберёмся, как не надо писать сообщения об ошибках.
«Вы хотите отправить разработчикам отчёт об ошибке в приложении?»
«Ok»
«Ну и ябеда!»
bash.im
Нам не привыкать — у нас за плечами многолетний опыт общения с разномастными продуктами отечественного софтостроения. Давайте уберём конкретику вовсе:
Счёт не может быть оплачен. Введены неправильные данные.
Чтобы ещё больше запутать пользователя, скроем от него причину ошибки:
Счёт не может быть оплачен.
Теперь приблизимся вплотную к нашему почти нулевому варианту:
Ошибка выполнения метода bill_payment.
Дальше для достижения антиидеала нам остаётся только убрать название метода и творчески преобразовать текст:
Неизвестная ошибка.
Интересно, не возникло ли у вас чувство дежавю, когда вы читали примеры в этом подразделе?
Добавляем информацию
В случае возникновения критической ошибки обновления:
1. Установите причину ошибки.
2. Устраните причину ошибки.
Документация Microsoft
Теперь давайте двигаться в другую сторону по нашей шкале — будем постепенно улучшать текст сообщения, руководствуясь правилами Сьюзан Уэйншенк.
Напомню исходный вариант сообщения из книги:
#402: до того как счёт может быть оплачен, необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Для начала преобразуем исходный текст, чтобы его легче было воспринимать:
#402: Для оплаты счёта необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Теперь расскажем пользователю, что он сделал не так:
#402: Вы ввели неправильную дату платежа — она раньше, чем дата создания счёта. Для оплаты счёта необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Выделим суть проблемы в отдельное предложение и явно объясним пользователю, что он должен сделать, чтобы её решить.
#402: Ошибка оплаты счёта. Вы ввели неправильную дату платежа — она раньше, чем дата создания счёта. Измените дату платежа так, чтобы она была позднее даты создания счёта.
Наконец, приведём конкретный пример. В данном случае нам известны даты и мы их можем использовать в тексте:
#402: Ошибка оплаты счёта. Вы ввели неправильную дату платежа 25.07.2021 — она раньше, чем дата создания счёта 29.07.2021. Измените дату платежа так, чтобы она была позднее даты создания счёта 29.07.2021. Например, 30.07.2021.
Мы существенно улучшили сообщение об ошибке — учли все правила и почти приблизились к идеалу. Но давайте поднимемся на уровень выше и подумаем, можно ли сделать так, чтобы ошибка не возникала вовсе.
Лучшее сообщение об ошибке
Ошибка выполнения метода: «Метод выполнился без ошибок».
Есть фразы, которые сразу хочется выписать на жёлтый стикер и приклеить где-то рядом с монитором. Одна из таких фраз: «Лучшее сообщение об ошибке — отсутствие сообщения об ошибке». Иными словами, часто бывает проще не допустить возможности возникновения ошибки, чем её описывать.
В нашем примере никто не мешает разработчику сделать две вещи:
При смене даты счёта очистить поле с датой платежа.
В интерфейсе запретить ввод даты платежа позже заданной даты счёта.
UPD: При этом неплохо бы подробно сообщить пользователю о причинах такого ограничения редактирования.
Эти незначительные изменения в коде позволят избежать ошибки вовсе. И не нужно будет ломать голову над текстом сообщения.
К сожалению, таким простым способом решить проблему удаётся не всегда. Мы не можем полностью обезопасить приложение от возникновения ошибок. Но в наших силах сделать сообщения об ошибках более информативными и полезными.
Статья была впервые опубликована на другом ресурсе 30 июля 2021.
Комментарии (21)
Akina
14.01.2022 08:39+7MySQL славен весьма точными сообщениями об ошибках, особенно в части указания точного места синтаксической ошибки в запросе.
OracleDB, наоборот, славен совершенно невменяемыми сообщениями об ошибках.
Oracle купил MySQL.
terrapod
14.01.2022 11:53+2Из ора напомнило:
ORA-600 [12235] "Oracle process has no purpose in life"
Но ведь понятно все.
Octember
14.01.2022 08:43+4
Прямо на больное наступили. До сих пор помню свое смятение, когда однажды увидел логи с кучей вот таких ошибок.
Soorin
14.01.2022 08:48+4Встречалось мне такое:
Ошибка времён DX4-133: "Обнаружена ошибка кода кольца 0".
Ошибка времён Vista при изменении файла Excel с текстом наподобие "Вы недостаточно овеществлены для выполнения данной операции".
vadimr
14.01.2022 09:16+4В нашем примере никто не мешает разработчику сделать две вещи:
При смене даты счёта очистить поле с датой платежа.
В интерфейсе запретить ввод даты платежа позже заданной даты счёта.
Эти незначительные изменения в коде позволят избежать ошибки вовсе. И не нужно будет ломать голову над текстом сообщения.
Автор так хорошо начал, а в результате предложил такую же “неизвестную ошибку” в интерфейсе, когда пользователь будет недоумевать, почему не получается ввести дату.
doctorw
14.01.2022 10:02+1Можно на отключённое поле навесить tooltip с текстом, почему поле недоступно
Mirzapch
14.01.2022 09:18+1В интерфейсе запретить ввод даты платежа позже заданной даты счёта.В одной известной программе в версии 8.1 примерно так и поступили.
sergarcada
14.01.2022 09:21+3Каких-то особенных ошибок не помню, но как-то раз одна из них удачно вписалась в новогодние обои
Приложение столкнулось с проблемой и упало? Пофиг, пляшем.
Kwisatz
14.01.2022 09:42+1Одни из самых крутых ошибок — у решений на базе 1с, каждый раз когда читаю «Ошибка Трали.вали.дили.дили.куча.сокр.ВННР.СорклЛП>0», хочется крови. Причем сами же потом не могут понять что не так, но когда объясняешь что стоит писать нормальные сообщения об ошибке, понимания нет вообще, даже у специалистов самых крупных компаний.
Зы
А вообще еще в Best Defence на эту тему хорошо показали (2:05)Заголовок спойлера
MentalBlood
14.01.2022 10:00-1Сообщение об ошибке при попытке открыть Microsoft Office
"Что-то пошло не так" звучит гораздо дружелюбней к пользователю, чем вываленные кишки программы. Дело в том, что ошибки бывают гораздо более глубокие и суровые, чем "Счёт не может быть оплачен. Введены неправильные данные."
Mingun
14.01.2022 10:35+3Они не разу не дружелюбный, потому что дружелюбная ошибка оставляет пользователю хоть какой-то шанс самостоятельно с ней справится, а не ставит его перед фактом, что "сегодня я не работаю, а ты, холоп,… дуй отсюда со своими проблемами". И даже при обращения в пресловутую поддержку пользователь сможет только сказать "Что-то не так", что запустит еще один круг бурления говен.
MentalBlood
14.01.2022 10:49+1Так там ниже написано что делать, и про поддержку ни слова
дружелюбная ошибка оставляет пользователю хоть какой-то шанс самостоятельно с ней справится
Дружелюбность ошибки зависит не только от соответствующего сообщения, но и от самой ошибки. Если это баг, то шансов исправить его у пользователя нет
nin-jin
14.01.2022 11:36+2А вот воркэркэраунд как правило есть. Но чтобы его загуглить - нужна хоть какая-то информация о произошедшем.
eurol
14.01.2022 11:18+2Была история с установкой драйверов и ПО принтера.
Запустили, оно делает вид, что установка идет. Мы долго ждем, понять не можем, что происходит. Появляется сообщение вида «Ошибка установки: установка идёт слишком долго» и кнопка «ОК». Офигев от такой наглости, я ушёл.
Потом приходит коллега и говорит: всё установилось. Я в непонятках: как?
Да просто запустили снова инсталлятор, в этот раз он, видимо, быстрее отработал.
nin-jin
14.01.2022 12:23+10Ошибка оплаты счёта. Вы ввели неправильную дату платежа 25.07.2021 — она раньше, чем дата создания счёта 29.07.2021. Измените дату платежа так, чтобы она была позднее даты создания счёта 29.07.2021. Например, 30.07.2021.
Теперь вспоминаем, что сообщения об ошибках гуляют где попало, поэтому надо удалить из них приватные данные:
Ошибка оплаты счёта. Вы ввели неправильную дату платежа — она раньше, чем дата создания счёта. Измените дату платежа так, чтобы она была позднее даты создания счёта.
Тут замечаем, что люди не любят, когда их в чём-то обвиняют и убираем тавталогию:
Для оплаты счёта необходимо, чтобы дата платежа была позднее, чем дата создания счёта.
Потом предполагаем, что пользователь скорее всего не страдает антероградной амнезией и удаляем информационный шум:
Дата платежа должна быть позднее даты создания счёта.
Теперь пользователь может за секунду понять, что пошло не так, и взяться за исправление, а не вчитываться в талмуды текста.
acmnu
14.01.2022 12:31+3Когда я работал в компании Stacksoft, один из разработчиков написал кучу хендлеров на обработку всех разумных и не разумных ошибок в одном важном блоке биллинга Onyma. Короче к блоку "else" его фантазия окончательно истощилась и он написал "Случилась такая неприятность, что я не знаю что и делать", поскольку он реально не знал что может означать заход в это ветвление и возможен ли он вообще.
И оно таки стрельнуло, правда очень не скоро, но жутко порадовало какого-то клиента.
rrust
14.01.2022 19:00+3о эта ошибка, которую вечно шлют на скриншотах и спрашивают посмотри что там сломалось.
SCCM Task Sequence Error 0X80004005
Да хз, эта ошибка означает что случилась некая ошибка, а все детали где-то выше по логу буквально 1-2 страницы выше.
Но люди всегда проматывают лог до самого конца именно до 0X80004005 и заботливо ее скриншотят, считая что она несет какую-то очень важную информацию.
Мне кажется что в микрософте местами сидят очень странные программисты
nerudo
У меня есть сообщение что-то типа «Произошла волшебная ошибка». Связана она с ситуацией, когда один признак статуса равен 1, другой — тоже 1. А результат их объединения по «И» — нулю. Пока, к удивлению, не возникала…