Використання NotImPLmentedException

Чи вважається поганою практикою кидати NotImplementedExceptionкод, про який ви ще не написали? Можливо, коментарі TODO вважатимуться безпечнішими?

Я вважаю NotImplementedException, що насправді є хорошою практикою.

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

Я рекомендую використовувати NotImplementedException комбіновану з коментарями TODO, щоб ви поєднували допомогу з графічним інтерфейсом (із завданнями в VS) та безпеку програми.

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

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

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

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

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

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

Я завжди використовую NotImplementedException- ось для чого це, зрештою.

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

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

Що це за проект? Робота чи дім? Вдома робіть все, що завгодно - все, що найкраще нагадує вам, що вам потрібно закінчити все, над чим ви працюєте.

На роботі закінчіть її писати.

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

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