Nunit: Поэтапный отказ от класса Guard

Созданный на 24 сент. 2018 · 4Комментарии · Источник: nunit/nunit

ReSharper и (в последние годы) Visual Studio предлагают вставлять ArgumentNullException и аналогичные проверки аргументов. Это такая мышечная память, что я несколько раз случайно вводил их в кодовую базу.

Прямой бросок более идиоматичен C# с точки зрения анализа управления потоком. Компилятор C# понимает, что вам не нужно возвращать значение или инициализировать переменную перед использованием или выходить из случая переключения, если вы используете throw вместо Guard . Точно так же выполняется проверка нулевого потока в ReSharper.

Кроме того, в C# 7.0 выражения throw могут быть удобными. Например, синтаксис _foo = foo ?? throw new ArgumentNullException(nameof(Foo)); .

Каковы другие плюсы или минусы разрешения участникам и нам самим создавать исключения напрямую вместо использования Guard?

Источник

jnm2

Самый полезный комментарий

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

Я довольно апатичен к исходу этого вопроса, меня все устраивает 😊

ChrisMaddock 24 сент. 2018

👍3

Все 4 Комментарий

Главный плюс использования класса Guard — это простота использования, если я правильно помню. В среде IDE, поддерживающей C#, это уже не самый простой вариант для меня или новых участников. Нужна ли нам последовательность, во всем или во всем? Последовательность противопоставляет то, что легче всего для одних из нас (потенциально), тому, что проще всего для других.

jnm2 24 сент. 2018

Я довольно апатичен к исходу этого вопроса, меня все устраивает 😊

ChrisMaddock 24 сент. 2018

👍3

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

Я не уверен, что нам нужна массовая чистка, но я не против этого.