C# 参数空验证该如何来处理呢？

80 阅读 0 评论 53 点赞

我是靠谱客的博主重要发卡，最近开发中收集的这篇文章主要介绍C# 参数空验证该如何来处理呢？，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

当我们在验证参数是否符合业务要求如何来做呢？以下示例伪代码

代码1：直接抛出一个异常

public void DoSomething ( Foo foo )
{
    if (foo is null )
    {
        //比如这里，是直接抛一个异常，还是如何解决呢？
        throw new ArgumentNullException( nameof (foo));
    }
}

代码2：返回一个NULL

 public T DoSomething(Foo foo)
 {
     T model=default(T);
     if (foo is null )
     {
         return model;
     }

     //继续dosometing

     //model = 正常业务赋值
     //
    return model
 }

Exception定义是表示在应用程序执行期间出现的错误，当我们在业务层没有将异常未得到解决，运行时会终止应用程序

性能注意事项

引发或处理异常会占用大量系统资源和执行时间。引发异常仅处理真正非凡的条件，而不是处理可预测的事件或流控制。例如，在某些情况下，例如在开发类库时，如果方法参数无效，则引发异常是合理的，因为预期使用有效参数调用方法。无效的方法参数（如果不是使用错误的结果）表示发生了异常。相反，如果用户输入无效，请不要引发异常，因为用户有时可能会输入无效数据。请改为提供重试机制，以便用户可以输入有效的输入。也不应使用异常来处理使用错误。请改用断言来识别和更正使用错误。

此外，当返回代码足够时不要引发异常;不要将返回代码转换为异常;并且不定期捕获异常，请忽略它，然后继续处理。

设计类，以避免异常

类可提供一些方法或属性来确保避免生成会引发异常的调用。

避免异常的另一方法是，对最常见的错误案例返回 null（或默认值），而不是引发异常。常见的错误案例可被视为常规控制流。通过在这些情况下返回 NULL（或默认值），可最大程度地减小对应用的性能产生的影响。

对于值类型，是否使用 Nullable<T> 或默认值作为错误指示符是应用需要考虑的内容。通过使用 Nullable<Guid>，default 变为 null 而非 Guid.Empty。有时，添加 Nullable<T> 可更加明确值何时存在或不存在。在其他时候，添加 Nullable<T> 可以创建额外的案例以查看不必要的内容，并且仅用于创建潜在的错误源。

我不太清楚如何解决这个问题？