Почему многие сообщения об исключениях не содержат полезных деталей?

220

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

Почему многие распространенные исключения из системных компонентов не содержат полезных деталей?

Несколько примеров:

  • .NET Listдоступ индекса ArgumentOutOfRangeExceptionникак не говорит мне значение индекса , который был испытанным и был недействительным, и не говорит мне допустимый диапазон.
  • В основном все сообщения об исключениях из стандартной библиотеки MSVC C ++ совершенно бесполезны (в том же духе, что и выше).
  • Исключения Oracle в .NET, сообщающие вам (перефразировано) «TABLE OR VIEW not found», но не какой именно .

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

Мартин Ба
источник
59
Следует отметить, что со стороны специалистов по безопасности «сообщения об ошибках не должны содержать подробностей о внутренностях системы» - это практическое правило.
Теластин
118
@Telastyn: Только если ваша система открыта для злоумышленников. Например, если вы используете веб-сервер, вы хотите, чтобы конечные пользователи передавали сообщения об ошибках, но вы все равно хотите, чтобы с вашей стороны регистрировались очень подробные сообщения об ошибках. А в клиентском программном обеспечении, где пользователь не является злоумышленником, вы определенно хотите, чтобы эти сообщения об ошибках были как можно более подробными, чтобы при возникновении проблем и отправке отчета об ошибке у вас было как можно больше информации для работы. насколько это возможно, потому что во многих случаях это все, что вы получаете.
Мейсон Уилер
9
@ Снеговик: Что недоступно для пользователя, если это программное обеспечение на стороне клиента? Владелец машины владеет машиной и может получить что угодно.
Мейсон Уилер
6
Всегда есть какая-то дополнительная информация, которую вы хотели бы получить. Я считаю сообщения, которые вы приводите в качестве примеров, довольно хорошими. Вы можете отладить проблему с ними. Гораздо лучше, чем «ошибка 0x80001234» (пример, вдохновленный Центром обновления Windows).
USR

Ответы:

204

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

Да, IndexOutOfRangeExceptionдолжен содержать точный индекс, выходящий за пределы диапазона, а также диапазон, который был действителен в момент его создания, и это презренно со стороны создателей среды выполнения .NET, чего нет. Да, table or view not foundисключение Oracle должно содержать имя таблицы или представления, которое не было найдено, и, опять же, тот факт, что это не так, является презренным от имени того, кто несет за это ответственность.

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

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

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

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

Чтобы ответить на озабоченность, выраженную Томасом Оуэнсом в комментарии ниже:

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

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

PS

Еще несколько моих мыслей на эту тему можно найти в этом ответе: Как написать хорошее сообщение об исключении

PPS

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

Майк Накис
источник
4
Я просмотрел некоторые классы исключений в .NET Framework, и оказалось, что существует множество возможностей для программного добавления такого рода информации. Поэтому я думаю, что вопрос решается на «почему они не делают». Но +1 за всю «читабельную» вещь.
Роберт Харви
7
Я не согласен, что исключения не должны содержать удобочитаемый компонент. На каком-то уровне вы можете создать сообщение журнала об исключении. Я бы сказал, что регистрация трассировки стека в читаемом пользователем файле журнала раскрывает детали реализации, которые вы не хотите раскрывать, поэтому читаемое человеком сообщение должно быть зарегистрировано. При представлении файла журнала, содержащего ошибку, разработчики должны иметь отправную точку, чтобы начать отладку, и иметь возможность вызвать исключение. Компонент, читаемый человеком, должен быть соответствующим образом детализирован, не отказываясь от реализации.
Томас Оуэнс
44
так программисты не люди? Глядя на моих коллег, это подтверждает некоторые подозрения, которые у меня были в течение некоторого времени ...
gbjbaanb
51
Опять же, нет ничего плохого в том, чтобы позволить пользователю видеть всю трассировку стека , если программное обеспечение находится на стороне клиента. Каждый профессиональный проект программного обеспечения, над которым я когда-либо работал, и большинство любительских проектов также содержали систему ведения журнала, которая генерировала бы полный дамп ошибок при возникновении необработанного исключения, включая полные трассировки стека всех работающих в настоящее время потоков в процесс. И пользователь может (задохнуться, о, ужас!) Посмотреть на него в любое время, когда захочет, поскольку это необходимо (не просто полезно, но необходимо ), чтобы отправить нам сообщение об ошибке! Что не так с этим?
Мейсон Уилер
13
Я также не убежден в отношении бинарных файлов журнала. Главным образом из-за моего опыта работы с systemd. Его специальный инструмент для просмотра этих журналов довольно запутанный и, кажется, был разработан комитетом обезьян Шекспира. Учтите, что для веб-приложения первым, кто увидит ваше исключение, часто будет системный администратор , и он захочет определить, нужно ли что-то исправить (например, на диске не хватило места) или передать обратно разработчикам.
Майкл Хэмптон
46

Почему многие распространенные исключения из системных компонентов не содержат полезных деталей?

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

  • Люди, ориентированные на безопасность, рассматривают исключения как источник утечки информации ( например ). Поскольку поведение исключений по умолчанию состоит в том, чтобы отображать эту информацию пользователю, программисты иногда ошибаются из-за осторожности.
  • В C ++ я слышал аргументы против выделения памяти в блоках catch (где, по крайней мере, часть контекста для создания хороших сообщений). Этим распределением сложно управлять, и, что еще хуже, оно может вызвать исключение нехватки памяти - часто происходит сбой приложения или утечка памяти. Трудно красиво форматировать исключения, не выделяя память, и эта практика может быть перенесена между языками, как это делают программисты.
  • Они не знают Я имею в виду, что есть сценарии, в которых код не знает, что пошло не так. Если код не знает - он не может сказать вам.
  • Я работал в местах, где проблемы с локализацией не позволяли вводить в систему только строки на английском языке - даже за исключением тех случаев, которые будут прочитаны только англоговорящим персоналом службы поддержки.
  • В некоторых местах я видел исключения, использованные больше как утверждения. Они там, чтобы предоставить ясное, громкое сообщение во время разработки, что что-то не сделано, или изменение было сделано в одном месте, но не в другом. Часто они настолько уникальны, что хорошее сообщение будет дублировать усилия или просто сбивать с толку.
  • Люди ленивы, программистов больше, чем большинство. Мы тратим гораздо меньше времени на исключительный путь, чем на счастливый путь, и это побочный эффект.

Мои ожидания не соответствуют? Я неправильно использую исключения, что я даже замечаю это?

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

Telastyn
источник
Я знаю, что это было помечено как C, но я должен добавить, что ваш последний абзац не относится ко всем языкам, так как некоторые могут (правильно или неправильно) в значительной степени полагаться на обработку ошибок на основе исключений и создание отчетов.
Лилиенталь
1
@Lilienthal - например,? Ни один язык, с которым я очень хорошо знаком, не занимается такими вещами регулярно.
Теластин
1
Я думаю, что в этом ответе много хорошего содержания, но в нем не говорится о сути дела: «Они должны».
Джечлин
3
Благодарю. Ваше беспокойство необоснованно (я надеюсь :-). Но каждый раз, когда я трачу лишнюю минуту на отслеживание того, что пошло не так в этом модульном тесте, или трачу дополнительное время на анализ кода, потому что в лог-файле не хватает информации, я немного раздражаюсь из-за того, что некоторые сообщения можно избежать, - это невозможно
Martin Ba
@Telastyn Собственная система SAP ABAP имеет конструкцию класса исключений, которая может содержать сообщение, которое в основном является объектом, специально предназначенным для сообщения пользователю о состоянии программы (успех, сбой, предупреждение) вместе с динамическим (многоязычным) сообщением. Я признаю, что не знаю, насколько широко распространены подобные вещи, или если это даже поощряется на языках, где это возможно, но есть, по крайней мере, один, где это (к сожалению) обычная практика.
Лилиенталь
12

У меня нет опыта работы с C # или C ++, но я могу сказать вам следующее - написанные разработчиком исключения в 9 из 10 раз более полезны, чем любое общее исключение, которое вы когда-либо найдете, точка.

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

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

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

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

Zibbobz
источник
7

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

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

Однако следует помнить о двух ключевых моментах: почему подробная информация об исключениях может быть нежелательной или важной:

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

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


источник
3
1. Исходя из этого критерия, представляется относительно произвольной, какая информация («Индекс вне диапазона», трассировка стека) и не отображается (значение индекса). 2. Отладка может быть намного быстрее и проще, когда известны соответствующие динамические значения. Например, он часто сразу сообщал бы вам, является ли проблема неправильным вводом фрагмента кода, или этот код неправильно обрабатывает корректный ввод
Бен Ааронсон,
@BenAaronson идентификатор / класс исключения говорит нам тип ошибки. Моя точка зрения - детали могут быть опущены (то есть, какое конкретное значение вызвало ошибку) для безопасности. Это значение может быть прослежено до ввода пользователя, раскрывая информацию злоумышленнику.
@ Снеговик Я не думаю, что безопасность важна, когда доступна полная трассировка стека, а номер индекса - нет. Конечно, я понимаю, что злоумышленник проверяет переполнение буфера, но многие исключения также оставляют совершенно безопасные данные (например, какая таблица Oracle не была найдена)
gbjbaanb
@gbjbaanb кто сказал, что нам нужно показать трассировку полного стека пользователю?
1
Спасибо, что поделились этим пониманием. Лично я не согласен и считаю, что аргумент безопасности - полная ошибка, но это может быть обоснованием.
Мартин Ба,
4

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

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

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

  • От 0 до 9 будет успех через успех с дополнительной информацией.
  • С 10 по 99 были бы не фатальные (исправимые) ошибки, и
  • С 101 по 255 будут фатальные ошибки.

(100 было почему-то опущено)

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

Когда код возвращался от подрядчиков, вы не поверите нашему удивлению, когда практически КАЖДАЯ ОДНА ФАТАЛЬНАЯ ОШИБКА была кодом возврата 101.

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

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

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

Последнее замечание: если сообщение об ошибке содержит код ошибки / возврата, мне кажется, что где-то в исполняемых модулях должна быть строка, которая читает что-то вроде «если условие возвращает код-значение», а условие должно сообщать вам, почему код возврата произошло. Это кажется простым логическим подходом, но, на мой взгляд, просто ПОПРОБУЙТЕ, чтобы Microsoft рассказала вам, что произошло, когда обновление Windows не удалось выполнить по CODE 80241013 или какому-то другому уникальному идентификатору. Вроде печально, не правда ли?

похотливый
источник
8
«... вы не поверите нашему удивлению, когда фактически КАЖДАЯ ОДНА ФАТАЛЬНАЯ ОШИБКА была кодом возврата 101». Вы правы. Я бы не поверил, что вы были удивлены, когда подрядчик последовал вашим инструкциям.
Одалрик
3
chances are the users will never write it down... and you will be told "Well it said something about a violation..." Вот почему вы используете инструмент регистрации исключений, чтобы автоматически генерировать отчет об ошибках, содержащий трассировку стека, и, возможно, даже отправлять его на ваш сервер. У меня был один пользователь, который не был очень техническим. Каждый раз, когда она отправляла сообщение из регистратора ошибок, оно показывало что-то вроде «Я не уверен, что я сделал неправильно, но ...», независимо от того, сколько раз я объяснял, что эта ошибка означала, что ошибка была на моей стороне , Но я всегда получал сообщения об ошибках от нее!
Мейсон Уилер
3

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

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

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

Но если вы поймаете исключение и сбросите его с помощью SQL-оператора, который вы пытались выполнить, вам будет лучше, так как оказывается, что вы попытались вставить запись с полем имени, являющимся Robert '); КАПЛИ СТОЛБОВ; (Всегда есть xkcd!)

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

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

изогнутый
источник
например, в C ++ вы должны использовать throw_with_nestedмного.
Майлз Рут
3

Чтобы дать немного другой ответ: нарушающий код, вероятно, был сделан для спецификации:

  • Функция получает X и возвращает Y
  • Если X недопустимо, выведите исключение Z

Добавьте давление, чтобы доставить точно к спецификации (из-за страха быть отклоненным в обзоре / тестировании) в минимальное время и с минимальными усилиями, тогда у вас есть рецепт для полностью совместимого и бесполезного исключения из библиотеки.

Стю Пегг
источник
3

Исключения имеют стоимость, зависящую от языка и реализации.

Например, исключения C ++ требуются для уничтожения всех живых данных между бросанием фрейма вызова и перехватом фрейма вызова, и это дорого. Следовательно, программисты не хотят часто использовать исключения.

В Ocaml генерирование исключений происходит почти так же быстро, как C setjmp(его стоимость не зависит от количества пройденных фреймов вызовов), поэтому разработчики могут использовать его очень часто (даже для неисключительных, очень распространенных случаев). Напротив, исключения C ++ достаточно тяжелые, поэтому вы, вероятно, не будете использовать их так часто, как в Ocaml.

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

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

Василий Старынкевич
источник
6
«Например, исключения C ++ требуются для уничтожения всех живых данных между бросанием фрейма вызова и перехватом фрейма вызова, и это дорого. Следовательно, программисты не хотят часто использовать исключения». Всего дерьма. Основная сила исключений C ++ состоит в том, что деструкторы вызываются детерминистически. Никто не будет использовать их, если они просто прыгнут.
Майлз Рут
Я знаю это, но фактом является то, что исключения C ++ не похожи на Ocaml, и вы не используете их, как в Ocaml.
Василий Старынкевич
5
Вы не используете исключения C ++ для потока управления в C ++ прежде всего потому, что это делает код нечитаемым и трудным для понимания.
Майлз Рут
-2

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

Исключения не являются механизмом обработки ошибок; они механизм восстановления .

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

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

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

Odalrick
источник
Я бы не назвал имя отсутствующей таблицы базы данных неуместным, хотя я понимаю и сочувствую вашей точке зрения. Я проголосовал за тебя.
Даниэль Холлинрейк
1
@DanielHollinrake Да, имя таблицы определенно наименее неуместно из примеров. В коде, с которым я работаю, такого рода проблемы удручающе распространены, и рассмотрение искажения имени таблицы дает понять, что не так. Я пытался придумать пример, почему эти вещи не имеют отношения к исключением; может быть, я могу использовать это ...
Одалрик
Я не согласен. Для обработки исключения дополнительные детали могут не потребоваться, поскольку вы просто хотите защитить приложение от сбоев, но, в конце концов, вам нужно будет сказать, почему оно не работает, и иметь возможность его исправить. Если у вас нет никаких подсказок, кроме типа исключения, тогда отладка хороша.
t3chb0t
@ t3chb0t Вот для чего нужна трассировка стека и класс исключения, дамп памяти и все остальное. Как это может помочь вам, если клиент позвонит и скажет: «Компьютер сообщает мне, что он пытался получить доступ к индексу 5, но его там не было». Это может помочь, только если вы также сериализуете список, контекст для списка и все остальное, что может быть полезно. Не следует сериализовать все состояние приложения каждый раз, когда вы генерируете исключение.
Одалрик
@Odalrick для клиента это может не иметь никакого значения , но как разработчик я ценю каждую информацию , которую я могу получить ;-) , то , может быть , еще один пример: скажем, SqlExeption происходит , и это все , что вы знаете ... Это гораздо проще восстановить его если вы знаете, какая строка подключения, база данных, таблица и т. д. не работали .... и это еще более важно, если ваше приложение использует несколько баз данных. Подробная трассировка стека требует, чтобы pdb-файлы были отправлены вместе с приложением ... это не всегда возможно. Также дампы памяти могут стать очень большими и не всегда могут быть переданы.
t3chb0t