Чому багато повідомлень про виключення не містять корисних даних?

Здається, існує певна угода, що повідомлення про виключення повинні містити корисні деталі .

Чому так, що багато поширених винятків із компонентів системи не містять корисних деталей?

Кілька прикладів:

• .NET Listдоступ індексу ArgumentOutOfRangeExceptionніяк НЕ каже мені значення індексу , який був випробуваним і був недійсним, і не говорить мені допустимий діапазон.
• В основному всі повідомлення про виключення зі стандартної бібліотеки MSVC C ++ є абсолютно марними (у тому ж ключі, що і вище).
• Винятки Oracle у .NET, які говорять вам (перефразовано) "ТАБЛИЦЯ АБО ПЕРЕГЛЯД не знайдено", але не який .

Отже, мені здається, що здебільшого повідомлення про виключення не містять достатньої кількості деталей, щоб бути корисними. Чи не відповідають мої очікування? Я неправильно використовую винятки, що я навіть це помічаю? Або , може бути , моє враження оманливе: більшість винятків робити на самому ділі забезпечують корисні деталі?

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

Так, IndexOutOfRangeExceptionповинен містити точний індекс, який був поза діапазоном, а також діапазон, який був дійсним на той момент, коли його викинули, і це зневажливо від імені творців .NET часу виконання. Так, table or view not foundвиняток Oracle повинен містити назву таблиці чи виду, які не знайдено, і знову ж таки, факт, що це не зневажливо від імені того, хто за це відповідає.

Значною мірою плутанина випливає з оманливої ​​оригінальної ідеї про те, що винятки повинні містити повідомлення, прочитані людиною, що, в свою чергу, випливає з нерозуміння того, що стосується винятків, тому це порочний цикл.

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

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

Отже, для нас, програмістів, "повідомлення" винятку є назвою класу винятку , і будь-яка інша інформація, яка стосується винятку, повинна бути скопійована у (остаточний / лише для читання) змінний член об'єкта винятку. Переважно, кожен окремий елемент його можна уявити. Таким чином, жодне повідомлення не потрібно (або повинно) генерувати, а отже, жодні сторонні очі не можуть його бачити.

Щоб вирішити стурбованість, висловлену Томасом Оуенсом у коментарі нижче:

Так, звичайно, на якому - то рівні, ви будете створювати повідомлення журналу щодо виключення. Але ви вже бачите проблему з тим, що ви говорите: з одного боку, повідомлення журналу винятків без сліду стека марно, але з іншого боку, ви не хочете, щоб користувач бачив весь слід стека винятків. Знову ж таки, наша проблема полягає в тому, що наша перспектива перекошена традиційними методами. Файли журналів традиційно були в простому тексті, що, можливо, було добре, поки наша дисципліна була в зародковому стані, але, можливо, не більше: якщо існує проблема безпеки, то файл журналу повинен бути двійковим та / або зашифрованим.

Будь то двійковий чи звичайний текст, файл журналу слід розглядати як потік, у який додаток послідовно розміщує інформацію про налагодження. Такий потік був би лише для очей програмістів, а завдання генерування налагоджувальної інформації для винятку повинно бути таким же простим, як серіалізація винятку в потоці журналу налагодження. Таким чином, дивлячись на журнал, ви бачите ім'я класу виключень (яке, як я вже зазначив, є для всіх практичних цілей "повідомленням"), кожну зі змінних членів винятку, що описують все, що доречно - і-практичне включення-в-журнал та весь слід стека. Зверніть увагу, як у цьому процесі помітно відсутнє форматування повідомлення, яке читається людиною, виключення .

PS

Ще кілька моїх думок з цього приводу можна знайти у цій відповіді: Як написати гарне повідомлення про виключення

PPS

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

Чому так, що багато поширених винятків із компонентів системи не містять корисних деталей?

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

• Люди, орієнтовані на безпеку, бачать винятки як джерело витоку інформації ( наприклад ). Оскільки поведінка винятків за замовчуванням полягає в тому, щоб відображати цю інформацію користувачеві, програмісти іноді помиляються на стороні обережності.
• У C ++ я чув аргументи проти розподілу пам’яті в блоки захоплення (де лежить хоча б частина контексту для створення хороших повідомлень). Цим розподілом важко керувати, і що ще гірше, це може спричинити виняток із пам'яті, який часто зберігається - часто виходить з ладу додаток або протікає пам'ять. Важко добре форматувати винятки без розподілу пам’яті, і ця практика може мігрувати між мовами, як це роблять програмісти.
• Вони не знають. Я маю на увазі, є сценарії, коли код не має поняття, що пішло не так. Якщо код не знає - він не може вам сказати.
• Я працював у місцях, де проблеми локалізації заважали вводити в систему лише рядки англійською мовою - навіть за винятками, які читатимуть лише співробітники служби підтримки англійською мовою.
• У деяких місцях я бачив, як винятки використовуються більше, як твердження. Вони там, щоб надати чітке, гучне повідомлення під час розробки, що щось не робиться, або в деяких місцях відбулася зміна, але не в іншому. Вони часто є досить унікальними, щоб гарне повідомлення було б дублювати зусилля або просто заплутати.
• Люди ліниві, програмісти більше, ніж більшість. Ми витрачаємо набагато менше часу на винятковий шлях, ніж щасливий шлях, і це побічний ефект.

Чи не відповідають мої очікування? Я неправильно використовую Винятки, що я це навіть помічаю?

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

У мене немає надлишків досвіду C # або конкретно C ++, але я можу вам сказати це - винятки, написані розробниками 9 з 10 разів, корисніші за будь-який загальний виняток, який ви коли-небудь знайдете, за період.

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

Ось так і має бути, оскільки як багато людей вказали, деякі програми не хочуть надсилати повідомлення про помилку, яке вони не хочуть, щоб користувач бачив їх з міркувань безпеки або щоб не заплутати їх.

Натомість ви повинні передбачити у своєму дизайні, які типи помилок можуть бути подані у вашій програмі (і завжди будуть помилки) та писати повідомлення про помилки, які допоможуть вам визначити проблему.

Це не завжди допоможе вам, тому що ви не завжди можете передбачити, яке повідомлення про помилку буде корисним - але це перший крок до кращого розуміння вашої власної програми.

Питання конкретно запитує, чому так багато винятків, викинутих "компонентами системи" (також стандартними бібліотечними класами), не містять корисних відомостей.

На жаль, більшість розробників не записують основні компоненти в стандартні бібліотеки, а також детальні проектні документи чи інші обгрунтування дизайну не обов'язково оприлюднюються. Іншими словами, ми можемо ніколи не знати точно.

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

1. Винятком може бути використаний виклик коду будь-яким способом: стандартна бібліотека не може розміщувати обмеження щодо використання винятку. Зокрема, він може відображатися користувачеві. Розгляньте індекс масиву поза межами: це може дати корисній інформації зловмиснику. Мовний дизайнер не має уявлення про те, як програма буде використовувати викинуте виняток або навіть який тип програми це (наприклад, веб-додаток або настільний ПК), тому вивільнення інформації може бути безпечнішим з точки зору безпеки.

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

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

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

Нещодавно у програмі, що перебудовується, було прийнято рішення про те, що коди повернення потраплять до однієї з трьох груп:

• 0 - 9 буде успішним завдяки успіху з додатковою інформацією.
• 10 - 99 були б не фатальними (відновлюваними) помилками та
• 101 - 255 були б фатальними помилками.

(100 чомусь залишили осторонь)

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

Коли код повернувся від підрядників, ви не повірите нашому здивуванню, коли практично ВСЕ ЄДИННА ФАТАЛЬНА ПОМИЛКА повертала код 101.

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

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

І давайте зіткнутися з цим, так як занадто багато (не все, але дуже багато) кодерів наступного покоління, якщо це більше роботи і не додає спалаху, просто не варто ...

Останнє зауваження: Якщо повідомлення про помилку включає код помилки / повернення, мені здається, що десь у виконаних модулях повинен бути рядок, який читає щось на кшталт "якщо умова повертає код-значення" та умова повинна розповісти вам, чому код повернення сталося. Це здається простим логічним підходом, але для мене життя, просто Спробуйте, щоб Microsoft повідомив вам, що сталося, коли оновлення Windows не вдалося на CODE 80241013 або якийсь інший дуже унікальний ідентифікатор. Як ні сумно, чи не так?

Хоча я згоден, що винятки повинні містити якомога більше інформації або принаймні бути менш загальною. У випадку не знайденого регістру таблиці ім'я таблиці було б добре.

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

У випадку, коли таблиця не знайдена, вона не допоможе вам сильно, якщо вам скажуть, що таблицю, яку неможливо знайти, називають СТУДЕНТИ, оскільки у вас немає такої таблиці, і ця рядок ніде у вашому коді.

Але якщо ви виберете виняток і повторно закинете його за допомогою SQL-оператора, який ви намагалися виконати, вам буде краще, так як виявиться, що ви намагалися вставити запис із полем імені " Роберт"); ДРОПУВАТИ СТУДЕНТИ СТОЛІ; (Завжди є xkcd!)

Отже, для боротьби з менш інформативними винятками: спробуйте вловити повторне винесення з додатковою інформацією, що стосується того, що ви намагалися зробити.

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

Щоб дати трохи іншу відповідь: Код порушника, мабуть, був зроблений для специфікації:

• Функція отримує X і повертає Y
• Якщо X недійсний, киньте виняток Z

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

Виключення мають вартість, пов’язану з мовою та впровадженням.

Наприклад, потрібні винятки C ++, щоб знищити всі живі дані між передачею кадру виклику та захопленням кадру виклику, і це дорого. Отже, програмісти не бажають багато використовувати винятки.

У Ocaml викид винятків відбувається настільки ж швидко, як і на C setjmp(його вартість не залежить від кількості кадрів пройденого виклику), тому розробники можуть використовувати його велику кількість (навіть для не виняткових, дуже поширених випадків). На відміну від цього, винятки на C ++ досить важкі, тому, ймовірно, ви не будете користуватися ними так, як у Ocaml.

Типовим прикладом є деякий рекурсивний пошук чи розвідка, який можна «зупинити» всередині досить глибокої рекурсії (наприклад, знайти листок у дереві чи функцію об’єднання). У деяких мовах швидше (так ідіоматичніше) поширити цю умову кожному абоненту. В інших мовах кидання винятку швидше.

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

Чому ви вважаєте, що значення індексу або необхідний діапазон чи назва таблиці є корисною деталлю, за винятком?

Винятки не є механізмом обробки помилок; вони є механізмом відновлення .

Суть винятків полягає в тому, щоб піднятися до рівня коду, який може обробляти виняток. Де б ви не знаходилися, вам потрібна інформація, або вона не є актуальною. Якщо є потрібна вам інформація, але ви не маєте негайного доступу до неї, ви не обробляєте виняток на відповідному рівні.

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

Я не кажу, що ви можете просто поставити "кинути новий виняток" скрізь і називати це хорошим, можна писати погані винятки. Але правильне використання їх, включаючи нерелевантну інформацію, не є обов'язковим.