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

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

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

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

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

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

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

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

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

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

28 голосов | спросил Moo-Juice 17 Jpm1000000pmMon, 17 Jan 2011 17:04:35 +030011 2011, 17:04:35

12 ответов


20

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

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

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

ответил George Marian 17 Jpm1000000pmMon, 17 Jan 2011 17:10:50 +030011 2011, 17:10:50
20

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

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

ответил David Thornley 17 Jpm1000000pmMon, 17 Jan 2011 18:06:29 +030011 2011, 18:06:29
7

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

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

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

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

Неприемлемый вид:

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

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

ответил Jon Hopkins 17 Jpm1000000pmMon, 17 Jan 2011 18:18:36 +030011 2011, 18:18:36
6

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

ответил Ryan Hayes 17 Jpm1000000pmMon, 17 Jan 2011 17:10:24 +030011 2011, 17:10:24
6

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

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

ответил ThomasW 17 Jpm1000000pmMon, 17 Jan 2011 17:26:52 +030011 2011, 17:26:52
3
  • Иногда слишком много информации может представлять угрозу безопасности; вы не знаете, кто читает сообщение об ошибке
  • Иногда операция, которая выбрала исключение, настолько сложна, что невозможно получить содержательное сообщение без негативных воздействий на скорость /сложность кода.
ответил StuperUser 17 Jpm1000000pmMon, 17 Jan 2011 17:11:24 +030011 2011, 17:11:24
3

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

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

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

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

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

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

ответил Ichthyo 17 Jpm1000000pmMon, 17 Jan 2011 21:57:05 +030011 2011, 21:57:05
2

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

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

ответил glenatron 17 Jpm1000000pmMon, 17 Jan 2011 18:45:20 +030011 2011, 18:45:20
2

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

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

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

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

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

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

ответил GWLlosa 17 Jpm1000000pmMon, 17 Jan 2011 18:48:25 +030011 2011, 18:48:25
2

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

  

Была сделана попытка интерпретировать бессмысленные данные

ответил smirkingman 17 Jpm1000000pmMon, 17 Jan 2011 18:51:49 +030011 2011, 18:51:49
0

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

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

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

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

ответил mctylr 17 Jpm1000000pmMon, 17 Jan 2011 19:39:05 +030011 2011, 19:39:05
0

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

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

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

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

ответил kizzx2 17 Jpm1000000pmMon, 17 Jan 2011 20:35:45 +030011 2011, 20:35:45

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132