Ви поставляєте, ви отримуєте рідкісну несправність в пробої. Перевірка вказівника чи відпустіть його?

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

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

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

Скажімо, програма не призначена для керованої ракети або автоматичної гальмівної системи ...

Який би ви вибрали?

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

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

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

3. Чи можна відтворити проблему на машині замовника? Чи можете ви отримати доступ до цієї машини? Це може бути справді цінним

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

_{У середовищі розвитку проблема може бути спіймана ствердженням.}

_{У певному порядку це було б зафіксовано та зафіксовано, але поточний зворотний слід ніколи не був спійманий.
Ви повинні мати можливість бачити, що пішло не так з дампами аварійного завершення, чи перевірили ви параметри тощо ...?}

Додаткові можливості, які можна зробити на основі часу, який ви хочете вкласти:

• Заархівуйте дамп аварійного завершення та посилайтеся на нього в коді з коментарем до рядка, який він зазнав аварії.
  Це дозволяє одному, хто вивчає дуже схожий дамб крашу, знати, що це відбулося раніше ...
  [витрачений час: короткий]

• Додаткові перевірки, ведення журналів, ... Ви хочете запобігти цьому та отримати додаткову інформацію наступного разу.
  [витрачений час: середній]

  У вашому коді сталося порушення нульового вказівника.

• Переконайтесь, що неможливо викликати програму таким чином, щоб це порушення мало місце.
  [витрачений час: довго]

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