Question

我在.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块中制作这个方法的主体。在这种情况下更好的是什么？

Answer 1

这取决于参数无效的可能性。无效参数例外或预期。

try...catch块将为正常情况提供更清晰的代码和更快的执行，但错误情况将执行得更慢。

因此，如果使用无效数据多次调用此方法，这将是您的应用程序中潜在的慢点，并且您拥有的代码将稍微提高效率。

Answer 2

您在此处使用的模式是错误的，因为它返回异常而不是抛出异常。我认为这是一个错误，否则你的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

我（显然）优先考虑第三种方法，因为：

它清楚地分隔了检查参数有效性的代码和执行实际工作的代码
它可以实现更精细的检查，而不是单一的检查，基本上告诉我某些事情是错误的，而没有指明什么
它位于方法的开头，可以隐藏在一个区域中，所以当我查看方法正确代码的核心性时，我不需要关注它。
很容易将抛出添加或更改为Asserts，日志语句或实际需要的任何内容

Answer 3

如果您使用的是.NET 4.0，则可以使用Code Cotracts。

检查参数以避免try..catch块（？）

3 个答案: