检查参数以避免尝试.捕获块(?).
本文关键字:参数 检查 | 更新日期: 2023-09-27 17:49:49
我在.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块。在这种情况下,什么更好?
你在这里使用的模式是错误的,因为它返回一个异常而不是抛出它。我认为这是一个错误的问题,否则你的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
我(显然)更喜欢第三种方法,因为:
- 它将检查参数有效性的代码和执行实际工作的代码进行了清晰的分离
- 它支持更细粒度的检查,而不是单一的检查,基本上告诉我什么是错误的,而不指定
- 它在一个方法的开始,可以隐藏在一个区域,所以当我审查方法正确的代码时,我不需要关注它。
- 很容易添加或更改抛出断言,日志语句或任何实际需要的
这取决于参数无效的可能性有多大。无效参数异常或预期。
在正常情况下,try...catch
块将导致代码更干净,执行速度更快,但错误情况将执行得更慢。
因此,如果这个方法被多次调用无效数据,这将是您的应用程序中一个潜在的慢点,使用您的形式的代码将稍微更有效。
如果你使用的是。net 4.0,你可以使用代码契约