Использование NotImplementedException

Считается ли плохой практикой бросать NotImplementedExceptionкод, который вы еще не написали? Возможно, комментарии TODO будут считаться более безопасными?

Я считаю, NotImplementedExceptionчто на самом деле это хорошая практика.

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

Я бы порекомендовал использовать NotImplementedException объединенные с комментариями TODO, таким образом, вы сочетаете помощь GUI (с задачами в VS) и безопасность программы.

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

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

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

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

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

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

Я всегда использую NotImplementedException - вот для чего это все- .

Это связано с понятием «быстро сбой»: если ваш код выдает исключение, это должно быть поймано перед началом работы. Если он доходит до производства, то, по крайней мере, клиент знает, что сборка неверна .

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

Что это за проект? Работа или дом? Дома делайте все, что хотите - все, что лучше всего напоминает вам, что вам нужно закончить то, над чем вы работаете.

На работе допиши.

Я не вижу ситуации, когда я проверял бы код, который может / сломает других разработчиков, QA или сборку.

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