【问题标题】:Exception vs. if statements [duplicate]异常与 if 语句 [重复]
【发布时间】:2015-01-27 12:00:00
【问题描述】:

我有 2 段代码。什么是最佳实践,为什么? 在第一个版本中,我添加了一个新商店并评估它是否通过异常成功,而在第二个版本中,我对“if”语句执行相同的操作。

我最近读到代码中的异常可能很昂贵,如果所有“添加”方法都以这种方式实现,则可能会导致性能问题。 有人可以确认吗?

谢谢!!!

public bool AddShop1(Shop newShop)
        {
            try
            {
                ShopDictionary.Add(newShop.ShopId, newShop);
                return true;
            }

            catch (ArgumentNullException)
            {
                return false;
            }

            catch (ArgumentException)
            {
                return false;
            }

        }

public bool AddShop2(Shop newShop)
        {
            if (newShop == null || ShopDictionary.ContainsKey(newShop.ShopId))
            {
                return false;
            }

            ShopDictionary.Add(newShop.ShopId, newShop);
            return true;
        }

【问题讨论】:

  • 您可以轻松地自己测试。是的,永远不要使用异常来驱动你的代码。

标签: c# performance exception if-statement null


【解决方案1】:

您不应该将 try catch 用于控制流逻辑。

应该使用 if 或 switch 等来完成。

try catch 应该只用于不确定的情况,然后应该进行相应的处理。

【讨论】:

    【解决方案2】:

    这取决于您的函数多久会导致异常。如果异常很少发生(每 1000 次调用一次),那么您可以忽略性能下降。但是如果从 1000 次执行中你会得到 800 个异常,那么肯定会转换为 ifs。但那只是一个问题,如果从 1000 个中有 800 个异常,这真的是异常,还是业务逻辑规则?

    【讨论】:

      【解决方案3】:

      嗯,避免异常对于您的应用程序的性能来说是更可取的。如果你真的对异常感兴趣,你可以这样做,

      public bool AddShop2(Shop newShop, out Exception exception)
          {
              exception = null;
              try
              {
                  if (newShop == null || ShopDictionary.ContainsKey(newShop.ShopId))
                  {
                      return false;
                  }
      
                  ShopDictionary.Add(newShop.ShopId, newShop);
              }
              catch (Exception ex)
              {
                  exception = ex;
              }
              return true;
          }
      

      【讨论】:

      • 性能为the weakest reason to avoid exceptions。您应该只在特殊情况下使用它们。
      • out Exception exception 我从未见过的签名。
      • @TimSchmelter,这就是我上面所说的,“避免异常对于性能来说更可取”。
      • @Magnus,当然这种模式不是标准的编码风格,但如果他想知道方法调用之外的异常原因,他可以通过这种方式得到它,或者要么返回异常布尔值。
      • @RohitPrakash:但我的观点是,性能不是避免异常的主要原因。引用 J.Skeet 的话:“如果您遇到异常严重影响性能的地步,那么您在使用异常方面就会遇到问题,而不仅仅是性能。”
      猜你喜欢
      • 1970-01-01
      • 2013-05-12
      • 2014-10-24
      • 2022-07-22
      • 2011-06-09
      • 1970-01-01
      • 1970-01-01
      • 2021-03-02
      • 2014-01-18
      相关资源
      最近更新 更多