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

15

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

Том Сквайрс
источник
6
В чем будет недостаток использования таких исключений для вас?
SRKX
@SRKX Существует риск попадания исключений в рабочий код, из-за чего весь блок кода не будет работать. (со мной еще не было, но у всех у нас выходных) Я лично ими пользуюсь, я волновался, что мог пропустить некоторые минусы.
Том Сквайрс
Как ни странно, ни один из тегов не указывает, какой язык используется. Это не относится ко всем распространенным языкам, так как C не имеет каких-либо исключений. Здесь есть место для языкового тега, ребята.
Дэвид Торнли
1
@DavidThornley, вопрос был изначально помечен как C #, поэтому я прочитал этот тег.
свик
@svick: думал, что это скорее всего C #. Спасибо за добавление тега.
Дэвид Торнли

Ответы:

34

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

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

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

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

SRKX
источник
6
Если вы используете Resharper, он показывает NotImplementedExceptions так же, как комментарии TODO. Я думаю, что это хорошая особенность.
свик
1
Добавьте хорошую практику TDD, и вы получите победителя
LRE
7

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

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

Майк Накис
источник
Это как если бы вы хотели иметь другое поведение в Debug и Release, и утверждение не всегда обрезает его. Я считаю, что .Net Code Contracts можно отключить в Release.
Работа
1
Я в основном использую утверждения, которые также отключены в релизе. У меня есть собственная функция подтверждения, которая достигает точки останова при отладке, вызывает исключение при тестировании или даже не компилируется при выпуске.
Майк Накис
3

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

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

FrustratedWithFormsDesigner
источник
1

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

Ларри Обриен
источник
1
Подожди .... ты имеешь в виду, где ты работаешь, код, который выдает NotImpl, прошел бы весь путь до QA? Даже в производство?
Стивен Эверс
3
Нет, как раз наоборот: NotImpl - это хороший огромный красный флаг / состояние ошибки. Но TODO не имеют семантической ценности и могут превратить их в тест или в производство, незаметно испортить ситуацию. (Я мог бы представить политику исключения TODO из производства, но у нас нет такого правила.)
Ларри OBrien
1

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

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

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

phoog
источник
0

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

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

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

Стивен Эверс
источник
Ну, и я тоже стараюсь придерживаться хороших практик дома.
Том Сквайрс
0

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

awiebe
источник