Класс статического броска: хорошая или плохая практика

Исключения броска часто следуют следующему шаблону:

if(condition) { throw exception; }

вы проверяете условие, и если условие выполняется, вы генерируете исключение. Итак, мне было интересно, стоит ли писать для него статический класс, который может выглядеть так:

public static class Throw
{
    public static void IfNullOrEmpty<T>(string @string, params object[] parameters) where T : Exception
    {
        Throw.If<T>(string.IsNullOrEmpty(@string), parameters);
    }

    public static void IfNullOrEmpty<T, I>(IEnumerable<I> enumerable, params object[] parameters) where T : Exception
    {
        Throw.If<T>(enumerable == null || enumerable.Count() == 0, parameters);
    }

    public static void IfNullOrEmpty(string @string, string argumentName)
    {
        Throw.IfNullOrEmpty(@string, argumentName, 
            string.Format("Argument '{0}' cannot be null or empty.", argumentName));
    }

    public static void IfNullOrEmpty(string @string, string argumentName, string message)
    {
        Throw.IfNullOrEmpty<ArgumentNullOrEmptyException>(@string, message, argumentName);
    }

    public static void IfNullOrEmpty<I>(IEnumerable<I> enumerable, string argumentName)
    {
        Throw.IfNullOrEmpty(enumerable, argumentName, 
            string.Format("Argument '{0}' cannot be null or empty.", argumentName));
    }

    public static void IfNullOrEmpty<I>(IEnumerable<I> enumerable, string argumentName, string message)
    {
        Throw.IfNullOrEmpty<ArgumentNullOrEmptyException, I>(enumerable, message, argumentName);
    }


    public static void IfNull<T>(object @object, params object[] parameters) where T : Exception
    {
        Throw.If<T>(@object == null, parameters);
    }

    public static void If<T>(bool condition, params object[] parameters) where T : Exception
    {
        if (condition) 
        {
            var types = new List<Type>();
            var args = new List<object>();
            foreach (object p in parameters ?? Enumerable.Empty<object>())
            {
                types.Add(p.GetType());
                args.Add(p);
            }

            var constructor = typeof(T).GetConstructor(types.ToArray());
            var exception = constructor.Invoke(args.ToArray()) as T;
            throw exception;
        }
    }

    public static void IfNull(object @object, string argumentName)
    {
        Throw.IfNull<ArgumentNullException>(@object, argumentName);
    }
}

(Примечание: ArgumentNullOrEmptyException здесь не определяется, но он делает многое, чего можно было бы ожидать.)

поэтому вместо многократного написания таких вещей

void SomeFunction(string someParameter)
{
   if(string.IsNullOrEmpty(someParameter))
   {
      throw new ArgumentNullOrEmptyException("someParameter", "Argument 'someParameter' cannot be null or empty.");
   }
}

я просто делаю

void SomeFunction(string someParameter)
{
   Throw.IfNullOrEmpty(someParameter, "someParameter"); // not .IsNullOrEmpty
}

Мне действительно нравится, но это также хорошая практика?

Ответы

Ответ 1

Вы избавляетесь от дублирования кода таким образом (if... throw), поэтому в этом смысле это хорошая идея. Просто имейте в виду, что люди, работающие над кодом, должны знать API Throw, чтобы иметь возможность читать и понимать код.

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

Например, в моем текущем проекте для животных у меня есть этот класс Guard (сокращенный бит):

public static class Guard
{
    public static void NotNullOrEmpty(Expression<Func<string>> parameterExpression)
    {
        string value = parameterExpression.Compile()();
        if (String.IsNullOrWhiteSpace(value))
        {
            string name = GetParameterName(parameterExpression);
            throw new ArgumentException("Cannot be null or empty", name);
        }
    }

    public static void NotNull<T>(Expression<Func<T>> parameterExpression)
        where T : class
    {
        if (null == parameterExpression.Compile()())
        {
            string name = GetParameterName(parameterExpression);
            throw new ArgumentNullException(name);
        }
    }

    private static string GetParameterName<T>(Expression<Func<T>> parameterExpression)
    {
        dynamic body = parameterExpression.Body;
        return body.Member.Name;
    }
}

Что я могу использовать следующим образом:

Guard.NotNull(() => someParameter);

Ответ 2

В этом шаблоне нет ничего плохого, и я видел это в ряде приложений. Это в основном вопрос личного стиля.

Однако есть одна вещь, о которой нужно знать с этим шаблоном: она изменяет перцептивную семантику для строк ресурсов. Это приложения/библиотеки, у которых есть локализованные сообщения об ошибках, которые шаблон имеет

if (...) {
  throw new ArgumentExecption("paramName", LoadSomeResource(ErrorId));
}

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