2010-10-21 3 views
7

при внедрении/использовании методов, возвращающих или работающих с экземплярами объектов, что является самым элегантным подходом для проверки параметров функции?Лучший способ проверить параметры функции: проверить на null или try/catch

Способ назвать:

someType GetSomething(object x) 
{ 
    if (x == null) { 
     return; 
    } 

    // 
    // Code... 
    // 
} 

или лучше:

someType GetSomething(object x) 
{ 
    if (x == null) { 
     throw new ArgumentNullException("x"); 
    } 

    // 
    // Code... 
    // 
} 

Вызов метода:

void SomeOtherMethod() 
{ 
    someType myType = GetSomething(someObject); 

    if (someType == null) { 
     return; 
    } 

} 

или лучше:

void SomeOtherMethod() 
{ 
    try { 
     someType myType = GetSomething(someObject); 
    } catch (ArgumentNullException) { 
    } 
} 

При просмотре похожих вопросов причина не использовать try/catch - это производительность. Но ИМХО попытка try-catch просто выглядит лучше :).

Итак, какой путь более «изящный»?

ответ

8

Если не указано значение null, отправьте исключение (т. Е. Это исключительная ситуация, которая должна произойти )).

Если null параметр is действителен, верните соответствующий объект.

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

+0

Имея функции, которые будут оценивать ненулевые входы и возвращать нуль для нулевых входов, часто является полезным шаблоном. В некоторых случаях шаблон Null Object может быть более приятным, но его сложно реализовать с помощью дженериков. – supercat

2

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

0

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

if (x != null) 
    someType myType = GetSomthing(x) 
else 
    // Initialize x or throw an InvalidOperation or return whatever is correct 

Однако, если его не очень личный, тогда вы должны сделать то, что Одед и другие сказали. Убедитесь, что в большинстве случаев он имеет значение null и бросает вызов ArguementExecption.

4

Что касается элегантности, то трудно найти Code Contracts.

Contract.Requires(x != null);