В чем проблемы разработчика с полезными сообщениями об ошибках? [закрыто]

29

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

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

Один пример из SQL Server. Когда вы пытаетесь восстановить базу данных, которая используется, она совершенно справедливо не позволит вам. SQL Server знает, какие процессы и приложения обращаются к нему. Почему он не может включать информацию о процессе (ах), которые используют базу данных? Я знаю, что не все передают Applicatio_Nameатрибут в строке подключения, но даже подсказка о рассматриваемой машине может быть полезной.

Другой кандидат, также SQL Server (и mySQL) - это прекрасное string or binary data would be truncatedсообщение об ошибке и его эквиваленты. Много времени, простое изучение оператора SQL, который был сгенерирован, и таблица показывает, какой столбец является виновником. Это не всегда так, и если механизм базы данных обнаружил ошибку, почему он не может сэкономить нам это время и просто сообщает нам, какой это был проклятый столбец? В этом примере вы можете утверждать, что при его проверке производительность может снизиться, и это может помешать автору записи. Хорошо, я куплю это. Как насчет того, чтобы ядро ​​базы данных узнало, что произошла ошибка, после этого оно быстро сравнивает значения, которые должны были быть сохранены, с длиной столбцов. Затем отобразите это пользователю.

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

Всякий раз, когда я выкидываю исключение из своего кода на C # или C ++, я предоставляю все, что у меня есть, под рукой. Было принято решение выбросить его, поэтому чем больше информации я могу дать, тем лучше. Почему моя функция выдает исключение? Что было передано и что ожидалось? Мне требуется немного больше времени, чтобы поместить что-то значимое в текст сообщения об исключении. Черт, это только помогает мне, пока я развиваюсь, потому что я знаю, что мой код выбрасывает вещи, которые имеют смысл.

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

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

Это 2011 ребята, приходите на .

design exceptions error-messages Moo-Сок
источник
11
Вау, это довольно напыщенная речь.
Джордж Мариан
3
@ Джордж, можете ли вы сказать, что я потратил много времени на то, чтобы отследить что-то, что действительно могло быть решено быстрее при соответствующей ошибке? :)
Му-сок
4
Я предлагаю глубокие вдохи, может быть, немного йоги и медитации. :) (Тем не менее, я точно знаю, что вы чувствуете.)
Джордж Мариан
2
+1 - «строка или двоичные данные будут обрезаны» всегда сводит меня с ума!
k25

Ответы:

22

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

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

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

Джордж Мариан
источник
+1 Я даже не думал об информационной перегрузке.
Райан Хейс
Я объяснил в своем посте, что я могу понять, почему некоторые считают, что многословие для конечного пользователя может быть бесполезным для них. Но вы говорите, что конечные пользователи API (например, адаптеры ASP.NET) или ядра базы данных (SQL-Server) не хотят многословных ошибок? Что-то, что могло бы спасти нас потенциально часами потерянного времени? Кстати, мне понравился каламбур :)
Moo-Juice
1
@ Джордж, также в отношении информационной перегрузки и ее полезности для конечного пользователя, опять же, я вижу случай, когда пользователь не запускает полную трассировку стека для текстового процессора, чтобы у него не было коричневого штанина и думаю, что они удалили интернет. Тем не менее, вы предоставили отличную альтернативу со сложной информацией в файле журнала. Все, что нужно сделать сейчас, это добавить For further information, see log20111701.txt. Это было бы шагом в правильном направлении.
Му-сок
2
@moo В конечном счете, я говорю, что это легко критиковать. (Я знаю, я делаю это часто.) Однако я стараюсь помнить, что не всегда легко определить, какой объем информации вы должны включить в сообщение об ошибке. Есть много раз, когда мне приходилось возвращаться и выводить более подробную информацию, чем я изначально ожидал во время отладки. Кроме того, во многих случаях сообщение об ошибке оказалось не таким полезным, как я ожидал при его создании.
Джордж Мариан
1
@moo Суть проблемы в том, что не всегда очевидно, сколько информации полезно. Представленные вами примеры кажутся довольно очевидными. Однако это нелегко распространить на общий случай.
Джордж Мариан
21

Разработчики не те люди, которые пишут сообщения об ошибках.

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

Дэвид Торнли
источник
+1 Для многих ошибок Framework / API часть проблемы заключается в том, что разработчик библиотеки не может знать контекст. Тем не менее, OP, по-видимому, в основном занимается сообщениями об ошибках типа «что-то не так, но я не собираюсь сообщать вам, где я знаю». Я думаю, это безопасность, верно?
МВД
8

Благотворительный взгляд:

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

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

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

Нечестивый взгляд:

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

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

Джон Хопкинс
источник
Я понимаю, откуда вы во многих случаях конечного пользователя. Тем не менее, случаи, которые я описал в моем первоначальном посте, могут часто происходить при написании кода для баз данных. Что касается приложений для конечных пользователей , таких как текстовый процессор или компьютерную игру, ошибки , как правило , не должно происходить , если что - то плохое не происходит, и даже тогда ошибка не может означать ничего конечному пользователю ( Process Handle Raped By Spawned Injector, Quitting SYstem..... user: "wtf я сделал?`). Но в случае с SQL Server / ASP.NET я думаю, что можно было бы приложить больше усилий :)
Moo-Juice
@ Moo-Juice - я думаю, что все сводится к "сообщениям об ошибках". Под капотом то, что на самом деле бросается в базу данных после того, как оптимизатор сделал это, имеет лишь мимолетное сходство с тем, что вы ему бросили. Выявление ошибки - это одно, а отслеживание того, что случилось с тем, что вы передали, - это совсем другое и абсолютно нетривиальное.
Джон Хопкинс
некоторые случаи могут быть не тривиальными. Я где-то просто немного кода, который ловит string/binary dataошибку, которая извлекает всю информацию столбца из указанной таблицы, анализирует прошлые значения и показывает, какие столбцы были бы нарушением. Это было тривиально. Может быть, я слишком сильно скучаю, потому что мои примеры кейсов тривиальны, но я полностью понимаю, что это не всегда так. Как мы не дадим порожденным инжекторам изнасиловать процессы, может быть довольно сложно :)
Moo-Juice
6

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

Райан Хейс
источник
Ах, да, хорошая мысль. Это всегда вызывает озабоченность стоимостью.
Джордж Мариан
Я могу согласиться с ценовой перспективой (и, черт побери, это не значит, что мне это нравится ). Я не могу говорить с точки зрения разработчиков SQL Server или ASP.NET, но я знаю , что он не принимает , что много дополнительных усилий , чтобы обеспечить имя столбца. Я признаю, что для моего простого примера это может быть решено за час. Тогда есть другие 1000 ошибок, которые могут быть сгенерированы. Но они могли бы, по крайней мере, начать с обычных :)
Moo-Juice
конечно, я не знаю внутренностей SQL-сервера - но, вообще говоря, чаще всего у вас нет этой информации под рукой в ​​момент обнаружения ситуации ошибки. Формулировка типа «строка или двоичные данные» достаточно ясно показывает, что на месте ошибки даже неясно, было ли усеченное значение строкой или числом ...
Ichthyo
На некотором уровне это может быть допустимо, но та же проблема возникает даже в простых сценариях Perl, где просто добавляется $! к сообщению об ошибке было бы очень полезно. Писать 'die "$ path: $!" "Дешевле (с точки зрения времени разработчика), чем писать совершенно бесполезный" die "Could not open $ path" "
Уильям Перселл
6

Я согласен, что сообщения об ошибках должны быть как можно более конкретными.

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

ThomasW
источник
это еще хуже: хотя вы можете вызывать ошибки в очень специфических точках, для обработки ошибок вы вынуждены объединить несколько возможностей в класс ситуаций и обработать их с помощью единственного восстановления. Этот акт обобщения часто вынуждает вас отбрасывать еще больше скудной дополнительной контекстной информации.
Ихтио
Кстати ... этот механизм приводит к целому классу забавных сообщений об ошибках - в духе "Серьезная ошибка -567 в модуле dwarf678: Ошибка не обнаружена"
Ichthyo
4
  • Иногда слишком много информации может быть угрозой безопасности; Вы не знаете, кто читает сообщение об ошибке
  • Иногда операция, вызвавшая исключение, настолько сложна, что невозможно получить значимое сообщение без негативного влияния на скорость / сложность кода.
StuperUser
источник
Я ответил на ваш первый пункт, позволяющий изменить детализацию исключений, добавленных в ваш код. Ваш второй пункт спорный, учитывая, что в этот момент произошла ошибка, и скорость больше не является решающим фактором (imho). И если для создания подробного сообщения об ошибке требуется, чтобы PRIOR оказывал влияние на производительность, то я согласен. Переместите этот код в ПОСЛЕ исключения, которое было сгенерировано. Я не вижу ни одного из этих пунктов в качестве действительного аргумента против правильных сообщений об ошибках :)
Moo-Juice
Правда, я полагаю, что вы можете искать информацию после того, как что-то произошло, а не отслеживать то, что вам может понадобиться. Хотя, если вы находитесь во вложенных циклах, захват индексов / индексов может быть проблематичным.
StuperUser
-1 для первого пункта, с которым я не согласен, +1 для второго пункта.
Джон Хопкинс
1
@jon Сравните общее сообщение об ошибке при входе в систему и более конкретные сообщения об ошибках, которые на самом деле говорят вам, что пошло не так. например, «Мы не смогли найти эту комбинацию имени пользователя и пароля» против «Вы ввели неверный пароль.» / «Это имя пользователя не существует». Кажется, я вспомнил уязвимость в ASP.NET, где сообщение об ошибке было действительно полезно при взломе ключей шифрования.
Джордж Мариан
@ Джордж - я согласен с этим примером, но я не думаю, что он широко распространен. После того, как вам был предоставлен доступ к приложению, определенный уровень риска исчезает, так как вы можете предположить, что человек (а) авторизован и (б) может получить большую часть того, что требуется от фактического приложения.
Джон Хопкинс
3

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

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

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

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

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

Возможность потери контроля проистекает из того факта, что мы все делаем планомерно и упорядоченно .

Ichthyo
источник
Я должен не согласиться. Он знает, что что-то не так (он не может выполнить операцию). Знать, что что-то не так, означает знание того, почему это неправильно. Эта строка слишком большая для этого столбца (или столбца в этой таблице). Это может сказать мне, без особой работы. Это проклятый движок корпоративной базы данных. Это знает . Но это не передает эту информацию. Учитывая, что программист может написать запрос для запуска после того, как факт обнаружит, что ядро ​​базы данных может сделать то же самое. Это не секретные недокументированные аспекты. Просто дерьмовое сообщение об ошибке :)
Moo-Juice
хех ... ты должен основывать свои аргументы на логике, а не на злобном мышлении С каких пор компьютер знает что-нибудь? Это не голливудский кинотеатр. Программа - это жесткая, заранее организованная установка, и когда ваши предположения нарушаются, вы теряете контроль. Это действительно так сложно понять? Компьютер не понимает программу, и поэтому он не может понять, когда она идет не так. Почти всегда, когда запускается некоторая проверка непротиворечивости, выполнение уже выполнено тысячами операторов, и никто не знает, какие данные уже были повреждены. Все, что вы можете сделать, это ограничить урон
Ichthyo
2

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

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

glenatron
источник
1
извините, это довольно непрактично. Кто будет нести ответственность за управление этим индексным документом, за его точность? Как любая письменная документация, отдельная от кода, она будет устаревшей и начнет получать источник новых ошибок в тот самый момент, когда она будет написана.
Ихтио
Наоборот, это та вещь, которую скрипт может извлечь из исходного кода, если каждая ошибка имеет уникальный номер, и описание каждой также содержится в коде либо в виде (специально отформатированного) комментария, либо в виде строка. Таким образом, документ будет автоматически генерироваться при каждой сборке. Извлеченное сообщение может быть более подробным, чем то, что вы хотите, чтобы конечный пользователь увидел. Неплохая идея!
Жанна Пиндар
вам не нужен скрипт для этого - многие системы времени выполнения могут записывать номер строки или некоторую похожую информацию. К сожалению, это не помогает с первоначальной проблемой, потому что так мы просто знаем, где было обнаружено исключение, но мы не знаем, что пошло не так . Обнаружение последнего называется отладкой - на практике это более или менее трудоемкая и трудоемкая задача, выполняемая людьми.
Ихтио
Я с @Jeanne - достаточно просто, чтобы включить в код или иметь центральный индекс в коде с кодом ошибки и их интерпретацией. Как только узнаете, где было обнаружено исключение, этого может быть достаточно, чтобы сказать вам, что где-то есть проблема со средой, а не с чем-то в коде, который нужно искать.
Гленатрон
2

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

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

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

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

В этом примере полезная информация, которую вы запрашиваете с точки зрения процессов, которые могут использовать файл, или даже других потоков в БД, полностью выходит за рамки (программно). Там могут быть сотни классов, которые имеют дело с файлами БД; импорт в эти классы информации о любом другом процессе, использующем файлы, или о функциональных возможностях для доступа к файловой системе и просмотра других запущенных процессов (при условии, что эти процессы даже находятся на ЭТОМ компьютере) приведет к так называемой утечке абстракции ; в производительности есть прямые затраты.

Вот как такие ошибки могут сохраняться в наши дни. Очевидно, они все МОГУТ быть исправлены; но во многих случаях это связано с гораздо большими накладными расходами, чем можно подумать (в этом случае, например, вам может потребоваться, чтобы эта функция пересекала перечисление сетевых подключений и общих ресурсов, чтобы увидеть, использует ли удаленный компьютер этот файл базы данных для некоторых причина) и стоимость далеко не тривиальна.

GWLlosa
источник
@ GWLlosa, это отличный ответ, который я не учел. Тем не менее (и я не могу предоставить полный пример кода здесь), когда я получаю это IOException, прежде чем я брошу свой GenericException, я мог бы 1) Спросить у Processesподсистемы список процессов. 2) Спросите у каждого процесса, какую базу данных они используют. 3) Сопоставьте процесс с базой данных, назначенной той, которую я пытаюсь перезаписать, 4) сгенерируйте DatabaseInUse(dbName, processName, applicationNameисключение. :)
Moo-Juice
1
Конечно, возможно; но код для сопоставления БД с процессом (особенно по сети) сам по себе может быть сложным / медленным / подверженным ошибкам, что может привести к некоторому дополнительному разочарованию («Я просто пытаюсь восстановить локальный (* #% ^!»). % file !!!! ПОЧЕМУ Я ЗАБОТАЮСЬ, ЧТО СЕТИ АКЦИИ НЕ ДОСТУПНЫ! ??!?! ")
GWLlosa
1
@ Moo-Juice: то, что вы предлагаете, звучит довольно наивно. В массивной многопоточной среде, такой как база данных, вы не можете просто обратиться к какой-либо глобальной службе, чтобы получить список «всех xyz». Даже для общения с каким-либо другим сервисом в другом потоке вам нужна блокировка, которая может привести к тупиковой ситуации всей системы в худшем случае, она может повредить другие данные или, по крайней мере, это может вызвать дополнительные ошибки, которые вы также должны затем обработать. ....
Ихтио
1
Этот пример действительно очень поучителен: как правило, в таком обработчике перехвата вы даже не можете точно сказать, какая часть в блоке try завершилась неудачно (обычно есть несколько частей, которые могут вызвать IOException). Кроме того, очень вероятно, что в этом месте вы не можете указать имя файла, чтобы вы не могли определить, какая логическая таблица соответствует этому файлу.
Ихтио
@Ichthyo, без обид, но я не думаю, что это наивно. Я не прошу ядро ​​базы данных заблокировать систему, чтобы сказать мне, какой процесс все еще имеет дескриптор базы данных. Я не прошу это остановить все предприятие. Если мне нужно дать мне простой ответ, то это, в первую очередь, показывает фундаментальный недостаток сервера баз данных. Помните, что он должен быть предназначен для того, чтобы предоставлять соответствующую информацию максимально быстрым способом. Чтобы задать ему вопрос "кто?" на самом деле не должно быть таким наивным, как вы заявляете :)
Moo-Juice
2

Моим фаворитом был (еще в конце 70-х) компилятор Univac Fortran IV, когда он читал не цифры, честно объявил

Была предпринята попытка интерпретации бессмысленных данных

smirkingman
источник
+1, абсолютно фантастика! Это ошибка, из-за которой вы просто хотите сдаться и пойти и разводить цыплят на Фиджи.
Му-сок
действительно, это сообщение об ошибке является на 100% точным - если вы хотите более дружелюбное сообщение с большим количеством контекста, вам нужно встроить некоторые догадки и эвристику; таким образом вы добавляете возможность вводить в заблуждение сообщения об ошибках ..
Ichthyo
0

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

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

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

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

mctylr
источник
0

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

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

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

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

kizzx2
источник