tgoop.com/csharp_gepard/127
Create:
Last Update:
Last Update:
Атрибут DoesNotReturn #решение
Когда мы пишем оптимальный код, мы пытаемся вынести выброс Exception за пределы тела метода, чтобы упростить inline. Типичная ситуация выглядит следующим образом:
public object MyMethod() {
var data = ...
if (data == null) {
Error.MyError("msg");
}
return data;
}
public static Error {
public static void MyError(string msg) {
throw new Exception(msg);
}
}
В этом случае статический анализатор (конечно, при включённом nullable annotations) вежливо подсказывает -
data
может быть null
(см. скриншот). Это правильно и нормально, так как возвращаемое значение метода не отмечено как object?
, то есть оно не допускает значение null.Некоторе, в подобной ситуации, кричат на код ("я знаю что делаю, дурацкая ты железка"), просто делая
return data!
. Однако, когда код будет меняться и разрастаться, логика первоначального создателя может изменится или утратиться, а криков на код станет больше.Есть, однако, другое решение, которое я подсмотрел в BCL - атрибут DoesNotReturn. Этот атрибут указывает компилятору, что метод или свойство никогда не возвращает значение. Другими словами, он всегда создаёт исключение (выполнение вызывающего метода прекратится).
Обладая этими нехитрыми знаниями, мы просто добавляем атрибут
DoesNotReturn
для всех методов, которые выбрасывают ошибку и убираем крики на код. Просто и красиво.[DoesNotReturn]
public static void MyError(string msg) {
throw new Exception(msg);
}
Более подробно про помощь компилятору можно прочитать тут и тут. Там же много других полезных атрибутов, которые помогут меньше кричать на код, а значит сделать его красивее и понятнее. Кажется, что все эти атрибуты особенно важны для библиотечного кода, тогда как в обычном коде они представляются мало востребованными.
BY C# Heppard

Share with your friend now:
tgoop.com/csharp_gepard/127