Я думав над цим питанням деякий час, і мені було б цікаво мати думки інших розробників.
У мене, як правило, дуже захисний стиль програмування. Мій типовий блок або метод виглядає так:
T foo(par1, par2, par3, ...)
{
// Check that all parameters are correct, return undefined (null)
// or throw exception if this is not the case.
// Compute and (possibly) return result.
}
Крім того, під час обчислення я перевіряю всі вказівники, перш ніж їх вивести. Моя ідея полягає в тому, що, якщо є якась помилка, а десь з’явиться вказівник NULL, моя програма повинна добре впоратися з цим і просто відмовитися продовжувати обчислення. Звичайно, він може повідомити про проблему за допомогою повідомлення про помилку в журналі або іншому механізмі.
Якщо говорити більш абстрактно, то мій підхід такий
if all input is OK --> compute result
else --> do not compute result, notify problem
Інші розробники, серед яких і мої колеги, використовують іншу стратегію. Наприклад, вони не перевіряють покажчики. Вони припускають, що фрагмент коду має бути введено правильним, і він не повинен відповідати за те, що станеться, якщо введення неправильне. Крім того, якщо виняток вказівника NULL руйнує програму, помилка буде виявлена легше під час тестування та матиме більше шансів виправитись.
Моя відповідь на це зазвичай: але що робити, якщо помилка не виявлена під час тестування і з’являється, коли продукт вже використовується клієнтом? Який бажаний спосіб проявити помилку? Це повинна бути програма, яка не виконує певну дію, але все ще може продовжувати працювати, або програма, яка виходить з ладу і потребує перезавантаження?
Узагальнення
Який із двох підходів до поводження з неправильним введенням ви б порадили?
Inconsistent input --> no action + notification
або
Inconsistent input --> undefined behaviour or crash
Редагувати
Дякуємо за відповіді та пропозиції. Я також шанувальник дизайну за контрактом. Але навіть якщо я довіряю людині, яка написала код, називаючи мої методи (можливо, це я сама), все одно можуть бути помилки, що призводять до неправильного введення. Тож мій підхід полягає у тому, щоб ніколи не вважати, що метод передається правильним введенням.
Також я б застосував механізм, щоб вирішити проблему та повідомити про неї. У системі розробки, наприклад, відкриється діалогове вікно, щоб сповістити користувача. У виробничій системі вона просто записує деяку інформацію в журнал. Я не думаю, що додаткові перевірки можуть призвести до проблем з роботою. Я не впевнений, чи достатньо тверджень, якщо вони відключені у виробничій системі: можливо, у виробництві виникла якась ситуація, яка не відбулася під час тестування.
У всякому разі, я був дуже здивований, що багато людей дотримуються протилежного підходу: вони дозволяють програмі вийти з ладу "навмисно", оскільки вони стверджують, що це полегшить пошук помилок під час тестування.