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

Существует два способа перенаправления

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

<?php 

header("Location: http://example.com/page.php");
die();
?>

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

<script>

     $(document).ready(function(){
    location.href = 'http://example.com/page.php';
     });

</script>
18
задан Jared Russell 7 August 2010 в 09:12
поделиться

7 ответов

Создайте класс ArgChecker с чем-то вроде этого

  ArgChecker.ThrowOnStringNullOrEmpty(userName, "Username");

, где ThrowOnStringNullOrEmpty -

  public static void ThrowOnStringNullOrEmpty(string arg, string name)
  {
      if (string.IsNullOrEmpty(arg))
        throw new ArgumentNullException(name + " can't be null");
  }

. Вы также можете попробовать обработать список аргументов с помощью аргумента params, например:

  public static void ThrowOnAnyStringNullOrEmpty(params string[] argAndNames)
  {
       for (int i = 0; i < argAndName.Length; i+=2) {
          ThrowOnStringNullOrEmpty(argAndNames[i], argAndNames[i+1]);
       }
  }

и вызвать как this

  ArgChecker.ThrowOnAnyStringNullOrEmpty(userName, "Username", Email, "email");
17
ответ дан 30 November 2019 в 06:19
поделиться

Подход, который я использую и, возможно, почерпнул из исходного кода NHibernate, заключается в создании статического класса Guard , используемого следующим образом:

public void Foo(object arg1, string arg2, int arg3)
{
    Guard.ArgumentNotNull(arg1, "arg1");
    Guard.ArgumentNotNullOrEmpty(arg2, "arg2");
    Guard.ArgumentGreaterThan(arg3, "arg3", 0);
    //etc.
}

public static class Guard
{
    public static void ArgumentNotNull(object argument, string parameterName)
    {
        if (parameterName == null)
            throw new ArgumentNullException("parameterName");

        if (argument == null)
            throw new ArgumentNullException(parameterName);
    }
    //etc.
}

Это сокращает много хлопот в начале методов, и он хорошо работает.

17
ответ дан 30 November 2019 в 06:19
поделиться

Вы должны подумать о методе, о том, что он должен делать и с какими данными. Если значения NULL представляют фактические условия отказа, используйте исключения. Если нулевые значения приемлемы, примите их.

Подумайте о принципах из проектирование по контракту , в частности, каковы предварительные условия для вашей функции, и стандартизируйте способ их применения (что Мэтт и Лу оба предлагают в их ответах, поэтому мне не нужно вдаваться в подробности)

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

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

9
ответ дан 30 November 2019 в 06:19
поделиться

И для разработчиков C # 3.0 среди нас отличный способ инкапсулировать эту нулевую проверку внутри метода расширения.

public void Foo(string arg1, int? arg2)
{
  arg1.ThrowOnNull();
  arg2.ThrowOnNull();
}

public static class extensions
{
    public static void ThrowOnNull<T>(this T argument) where T : class
    {
        if(argument == null) throw new ArgumentNullException();
    } 
}

И если вы хотите, вы всегда можете перегрузить это, чтобы получить имя аргумента.

5
ответ дан 30 November 2019 в 06:19
поделиться

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

Продолжайте проверять каждый аргумент отдельно, хотя вы или пальцы устают от ввода Grasshopper :) Ваши последователи будут благослови вас, когда они получают неожиданное исключение ArgumentException и сохраняются после выполнения отладки только для того, чтобы определить, какой из аргументов завершился ошибкой.

2
ответ дан 30 November 2019 в 06:19
поделиться

Небольшим улучшением ответа Лу было бы использование вместо этого хеш-таблицы, это означает, что он проверяет объекты, а также просто строки. Также удобнее заполнять и обрабатывать в методе:

public static class ParameterChecker
{
    public static void CheckForNull(Hashtable parameters)
    {
        foreach (DictionaryEntry param in parameters)
        {
            if (param.Value == null || string.IsNullOrEmpty(param.Value as string))
            {
                throw new ArgumentNullException(param.Key.ToString());
            }
        }
    }
}

Как вы бы использовали:

public User CreateUser(string userName, string password, string Email, string emailAlerts, string channelDescription)    
{
    var parameters = new Hashtable();
    parameters.Add("Username", userName);
    parameters.Add("Password", password);
    parameters.Add("EmailAlerts", emailAlerts);
    parameters.Add("ChannelDescription", channelDescription);
    ParameterChecker.CheckForNull(parameters);

    // etc etc
}
3
ответ дан 30 November 2019 в 06:19
поделиться

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

Вам не нужно проверять int или bool, которые не могут иметь значение null.

Строки можно проверить с помощью string.IsNullOrEmpty () ...

Если вы все же решите, что вы хотите проверить каждый параметр, вы можете либо использовать шаблон проектирования Command и отражение, но ваш код будет излишне неуклюжим, либо использовать следующее и вызывать его для каждого метода: частный myType myMethod (строка param1, int param2, byte [] param3) { CheckParameters ("myMethod", {param1, param2, param3}); // остальной код ...

И в вашем служебном классе поместите это:

///<summary>Validates method parameters</summary>
///... rest of documentation
public void CheckParameters(string methodName, List<Object> parameterValues) 
{
    if ( string.IsNullOrEmpty(methodName) )
       throw new ArgumentException("Fire the programmer! Missing method name", "methodName"));

    Type t = typeof(MyClass);
    MethodInfo method = t.GetMethod(methodName);
    if ( method == null )
       throw new ArgumentException("Fire the programmer! Wrong method name", "methodName"));
    List<ParameterInfo> params = method.GetParameters();
    if ( params == null || params.Count != parameterValues.Count )
       throw new ArgumentException("Fire the programmer! Wrong list of parameters. Should have " + params.Count + " parameters", "parameterValues"));

    for (int i = 0; i < params.Count; i++ )
    {
            ParamInfo param = params[i];
            if ( param.Type != typeof(parameterValues[i]) )
                throw new ArgumentException("Fire the programmer! Wrong order of parameters. Error in param " + param.Name, "parameterValues"));
            if ( parameterValues[i] == null )
                throw new ArgumentException(param.Name + " cannot be null");
    }
} // enjoy
-1
ответ дан 30 November 2019 в 06:19
поделиться
Другие вопросы по тегам:

Похожие вопросы: