Question

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

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

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

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

我们需要以不同的方式处理问题。也许当存在参数异常时，除了输出错误之外还要做其他事情。但他认为他的库正在处理所有事情，我们应该停止操作并输出错误。除了显示错误消息之外，我也无法想到我们需要以不同方式处理的案例的许多具体示例。但我觉得我们可能需要它，我担心我只是违反YAGNI原则。
我认为如果他错了，我们需要在不同的情况下处理不同的事情，我将不得不引入条件代码（如果错误是A然后这样做，如果B然后这样做）。这将很难处理。

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

你认为我们应该选择上一节课吗？如果您认为我们应该使用多个异常类，那么您的理由是什么？

Answer 1

如果错误代码可以在不同版本之间发生变化，那么任何工作量（或缺少工作量）都不会让您无法在某些时候以某种方式重新映射这些错误。如果您有代码（或代码范围）的例外情况，那么当错误代码发生变化时，您将很难更多工作，而不会有更多工作（您将重新排列什么异常）如果你没有专门的类，就像抛出一个例外的消息一样被抛出。

此外，在一般实践中，通过.NET约定，您应该为BCL提供的异常未适当覆盖的特定异常创建专用异常类（不包括仅用于抽象的那些异常的使用）

对于某些Microsoft输入，请考虑this：

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

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

[将]帮助确保您使用现有的适当的例外情况，并在它们之间创建新的例外为你的图书馆增加价值。

坚持你的枪。

Answer 2

你是对的。最好为不同类型的错误使用多个异常类（针对不同的错误代码）。异常是错误代码的一些后继者，因此最好使用异常。而且那个人提供的方法再次使用错误代码，由一个异常类包装。

带着他的号码的SqlException出现在我的脑海里。通过检查错误代码来捕获不同类型的错误是一种地狱。

Answer 3

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

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

例如，只要您想捕获某个异常，就会有一个非常具体的用例。即。

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

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

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