Проверка аргумента, чтобы избежать блока try..catch (?) - PullRequest
0 голосов
/ 13 апреля 2011

Я написал этот метод в файле .svc

 public SomeDTO Method1( byte[] bitmapAsByteArr, DTO1 dto1, DTO2 dto2 )
    {
        if( bitmapAsByteArr!= null && bitmapAsByteArr.Length > 0 && dto1!= null && dto2 != null )
        {
            return new SomeDTO(bitmapAsByteArr,dto1,dto2,1,2,3,4);
        }
        else
        {
            throw new ArgumentNullException();
        }
    }

Я бродил, если этот путь лучше, они делают тело этого метода в блоке try..catch. Что лучше в этом случае?

Ответы [ 3 ]

1 голос
/ 13 апреля 2011

Шаблон, который вы здесь используете, неверен в том смысле, что он возвращает исключение, а не выбрасывает его. Я думаю, что это ошибка в вопросе, иначе ваш SomeDTO объект должен был бы быть каким-то образом связан с классом ArgumentNullException, и это совершенно неправильно.

Что вы можете сделать, это:
- Ваше решение, где мы проверяем все аргументы на достоверность, а затем делаем работу

if (are_all_arguments_ok)
{
   //procedure code, possibly hundreds of lines
}
else
{
   throw new SingleExceptionForAnyParameterIssues();
}

- Вставить код в try..catch, например

try
{
   //procedure code, possibly hundreds of lines
}
catch
{
   //not really sure what we caught here
   //could be a parameter problem, could be a code problem
   throw new SingleExceptionForAnyParameterIssues();
}

- проверка параметров в начале метода

if (param1_is_null)
{
   throw new ArgumentNullException("param1");
}
if (param1_is_invalid)
{
   throw new ArgumentException("bad, bad param1","param1");
}
// other parameters are checked here

//procedure code, possibly hundreds of lines

Я (явно) предпочитаю третий метод, потому что:

  • Это дает четкое разделение кода, который проверяет правильность параметров, и кода, который выполняет фактическую работу
  • Позволяет выполнять более точные проверки вместо одной проверки, которая в основном говорит мне, что что-то не так, без указания того, что
  • Он находится в начале метода и может быть скрыт в области, поэтому мне не нужно сосредотачиваться на нем, когда я проверяю суть правильного кода метода.
  • Легко добавить или изменить броски на Утверждения, оператор записи или все, что действительно нужно
1 голос
/ 13 апреля 2011

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

Блок try...catch приведет к более чистому коду и более быстрому выполнению для обычного случая, но случай ошибки будет выполняться медленнее.

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

0 голосов
/ 13 апреля 2011

Вы можете использовать Code Cotracts , если вы используете .NET 4.0.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...