使用多个特殊异常类

本文关键字：异常 | 更新日期: 2023-09-27 17:56:33

对于我们在我工作的公司开发的软件，我们使用一个第三方库，该库是由我们经常接触的人开发的。他的代码是用C++编写的，我们在项目中使用 C#。

通常，他的库函数返回错误代码。我决定使用不同的异常类来涵盖不同范围的错误代码。例如，一个异常类用于参数处理错误，一个异常类用于主操作错误，一个异常类用于输入值错误等。

他认为这不是一个好主意，并建议对库使用一个异常类来捕获所有错误，然后从XML文件中获取错误代码并将问题输出给用户。他认为，写一个以上的异常类是没有意义的。他还说，他不能保证不同版本的库中的错误代码是相同的。

我认为拥有多个异常类是个好主意，因为：

  1. 可能有不同的情况，我们需要以不同的方式处理问题。也许当出现参数异常时，做其他事情，而不仅仅是输出错误。但他认为他的库正在处理所有事情，我们应该停止操作并输出错误。我也想不出许多我们需要以不同方式处理的情况的具体例子，除了显示错误消息。但我觉得我们可能需要它，我担心我只是违反了YAGNI原则。
  2. 我认为如果他被证明是错误的，并且我们需要在不同情况下以不同的方式处理事情，我将不得不引入条件代码（如果错误是 A，则执行此操作，如果 B 则执行该操作）。而且很难处理。

我认为以我们可以不同方式处理不同类型的异常的方式来开发程序是一个更好的主意。但是这个家伙比我有更多的经验，而且他在公司里有更多的可信度（我是一个新实习生），我对软件开发很陌生，我觉得也许他是对的，我只是想添加额外的代码，因为它看起来很漂亮，违反了 YAGNI 原则。

你认为我们应该上一个或更多的班级吗？如果您认为我们应该使用多个异常类，您的原因是什么？

使用多个特殊异常类

如果错误代码可以从版本更改为版本，那么再多的工作（或缺乏工作）也无法为您省去在某些时候以某种方式重新映射这些代码的麻烦。如果你的代码（或代码范围）有例外，那么当错误代码确实发生变化时，它几乎不会比没有时多得多的工作（你将重新排列抛出的异常，就像如果你没有专门的类，你必须为一个异常摇晃消息）。

此外，在一般做法中，根据 .NET 约定，应为 BCL 提供的异常未适当涵盖的特定异常创建一个专用的异常类（不包括其中仅用于抽象的异常的使用）。

对于某些Microsoft输入，请考虑以下事项：

应用程序和库不应使用返回代码来传达错误。

而这个：

考虑抛出驻留在系统中的现有异常 命名空间，而不是创建自定义异常类型。

但是，遵循异常设计指南，

[将] 帮助确保您使用现有的 例外（如适用），并在 为您的图书馆增加价值。

坚持己见。

你是对的。最好对不同类型的错误（针对不同的错误代码）使用多个异常类。异常在某种程度上是错误代码的继承者，因此最好使用异常。这家伙提供的方法再次使用错误代码，由一个异常类包装。

SqlException和他的数字浮现在我的脑海中。通过检查错误代码来捕获不同类型的错误真是太糟糕了。

您绝对应该使用多个异常类。 请注意，在System命名空间中已经有大量内置类，例如ArgumentNull和朋友。

如果要查看未使用多个异常的情况，请查看 COM 互操作。这是一个黑暗的地方，抛出了通用的异常，它们的推理由单个整数HRESULT证明是合理的。相信我，你不想重现它。

不过，一个非常具体的用例是，例如，当您只想捕获某个异常时。

try
{
  lib.OpenFile(mypath);
}catch(FileNotFoundException e)
{
 //handle gracefully and possibly "ignore" this error 
}

在这里，如果找不到文件，您需要执行其他操作。但是，如果OpenFile因为 mypath null 而引发异常，您可能希望此异常冒泡并引发错误。（至少这样你就可以记录它或其他东西）。使用单个异常类，这变得更加痛苦

catch(MyException e)
{
  if(e.Reason=10)
  {
  }else{
    throw; //rethrow exception(which makes debugging more difficult)
  }
}
相关文章：