C# 我可以从我的应用程序中抛出哪些内置的 .NET 异常？

Which built-in .NET exceptions can I throw from my application?

提问by Simon Keep

If I need to throw an exception from within my application which of the built-in .NET exception classes can I use? Are they all fair game? When should I derive my own?

如果我需要从我的应用程序中抛出异常，我可以使用哪些内置的 .NET 异常类？他们都是公平的游戏吗？我什么时候应该派生我自己的？

采纳答案by Ash

See Creating and Throwing Exceptions.

请参阅创建和抛出异常。

On throwing built-in exceptions, it says:

在抛出内置异常时，它说：

Do not throw System.Exception, System.SystemException, System.NullReferenceException, or System.IndexOutOfRangeException intentionally from your own source code.

不要从您自己的源代码中故意抛出 System.Exception、System.SystemException、System.NullReferenceException 或 System.IndexOutOfRangeException。

and

和

Do Not Throw General Exceptions

If you throw a general exception type, such as Exception or SystemException in a library or framework, it forces consumers to catch all exceptions, including unknown exceptions that they do not know how to handle.

Instead, either throw a more derived type that already exists in the framework, or create your own type that derives from Exception."

不要抛出一般异常

如果在库或框架中抛出一般异常类型，例如 Exception 或 SystemException，它会强制使用者捕获所有异常，包括他们不知道如何处理的未知异常。

相反，要么抛出框架中已经存在的更多派生类型，要么创建您自己的从 Exception 派生的类型。”

This blog entryalso has some useful guidelines.

这个博客条目也有一些有用的指南。

Also, FxCop code analysis defines a list of "do not raise exceptions" as described here. It recommends:

此外，FxCop 代码分析定义了一个“不引发异常”的列表，如此处所述。它建议：

The following exception types are too general to provide sufficient information to the user:

• System.Exception
• System.ApplicationException
• System.SystemException

The following exception types are reserved and should be thrown only by the common language runtime:

• System.ExecutionEngineException
• System.IndexOutOfRangeException
• System.NullReferenceException
• System.OutOfMemoryException

以下异常类型过于笼统，无法向用户提供足够的信息：

• 系统异常
• System.ApplicationException
• 系统异常

以下异常类型是保留的，只能由公共语言运行时抛出：

• System.ExecutionEngineException
• System.IndexOutOfRangeException
• System.NullReferenceException
• System.OutOfMemoryException

So in theory you can raise any other framework exception type, providing you clearly understand the intent of the exception as described by Microsoft (see MSDN documentation).

因此，理论上您可以引发任何其他框架异常类型，前提是您清楚地了解 Microsoft 描述的异常的意图（请参阅 MSDN 文档）。

Note, these are "guidelines" and as some others have said, there is debate around System.IndexOutOfRangeException (ie many developers throw this exception).

请注意，这些是“指南”，正如其他一些人所说，围绕 System.IndexOutOfRangeException 存在争议（即许多开发人员抛出此异常）。

回答by leppie

I use the ArgumentException(and its “friends”) regularly.

我ArgumentException经常使用（及其“朋友”）。

NotSupportedExceptionand NotImplementedExceptionare also common.

NotSupportedException而且NotImplementedException也很常见。

回答by Stu Mackellar

You can create and throw pretty much any of them, but you generally shouldn't. As an example, the various argument validation exceptions (ArgumentException, ArgumentNullException, ArgumentOutOfRangeException, etc) are suitable for use in application code, but AccessViolationException isn't. ApplicationException is provided as a suitable base class for any custom exception classes you may require.

您几乎可以创建和抛出它们中的任何一个，但通常不应该。例如，各种参数验证异常（ArgumentException、ArgumentNullException、ArgumentOutOfRangeException 等）适合在应用程序代码中使用，但 AccessViolationException 不是。ApplicationException 作为您可能需要的任何自定义异常类的合适基类提供。

See this MSDN articlefor a list of best practices - it refers to handling exceptions, but also contains good advice on creating them...

请参阅此MSDN 文章以获取最佳实践列表 - 它指的是处理异常，但也包含有关创建它们的好建议......

回答by Konrad Rudolph

On the subject of System.Exceptionand System.ApplicationException: The latter was meant to be used as the base class of all custom exceptions. However, this hasn't been enforced consistently from the beginning. Consequently, there's a controversy whether this class should be used at all rather than using System.Exceptionas the base class for all exceptions.

关于System.Exceptionand的主题System.ApplicationException：后者旨在用作所有自定义异常的基类。然而，这并没有从一开始就始终如一地执行。因此，是否应该使用这个类而不是System.Exception用作所有异常的基类存在争议。

Whichever way you decide, neverthrow an instance of these two classes directly. It's actually a pity that they aren't abstact. For what it's worth, always try using the most specific exception possible. If there is none to meet your requirement, feel free to create your own. In this case, however, make sure that your exception has a benefit over existing exceptions. In particular, it should convey its meaning perfectly and provide all the information necessary to handle the situation in a meaningful manner.

无论您决定采用哪种方式，都不要直接抛出这两个类的实例。可惜他们不是abstact。对于它的价值，请始终尝试使用最具体的异常。如果没有满足您的要求，请随意创建自己的。但是，在这种情况下，请确保您的例外情况优于现有例外情况。特别是，它应该完美地传达其含义，并提供以有意义的方式处理情况所需的所有信息。

Avoid to create stub exceptions that don't do anything meaningful. In the same vein, avoid creating huge exception class hierarchies, they're rarely useful (although I can imagine a situation or two where I would use them … a parser being one of them).

避免创建没有任何意义的存根异常。同样，避免创建巨大的异常类层次结构，它们很少有用（尽管我可以想象一两种情况我会使用它们……解析器就是其中之一）。

回答by Scott Wisniewski

My advice would be to focus on two things:

我的建议是关注两件事：

1. Scenarios
2. User expectations

1. 场景
2. 用户期望

In otherwords, I would sit down and identify:

换句话说，我会坐下来确定：

1. Under what scenarios do you want to throw exceptions.
2. In those scenarios, what would the users of your API expect

1. 你想在什么场景下抛出异常。
2. 在这些场景中，您的 API 用户会期望什么？

The answer to #1 is, of course, application specific. The answer to #2 is "what ever similar code they are already familiar with does".

当然，#1 的答案是特定于应用程序的。对#2 的答案是“他们已经熟悉的类似代码会做什么”。

The behavior that comes out of this is:

由此产生的行为是：

1. Under the scenarios that arise in your programs that also arrive inside the framework, such as arguments being null, out of range, being invalid, methods not being implemented, or just not supported, then you should use the same exceptions the framework uses. The people using your APIs are going to expect that they behave that way (because that's how everything else behaves), and so will be better able to use your api from the "get go".

   2. For new scenarios that don't exist in the framework, you should go ahead and invent your own exception classes. I would say that you should prefer Exception as your base class unless their is some other base exception that provides services you need. Generally speaking I don't think something like "ApplicationException" will help you much. When you start defining your own exceptions there are a few things you should keep in mind though:

   a. The primary purpose of an exception is for human communication. They convey information about something that happened that shouldn't have. They should provide enough information to identify the cause of a problem and to figure out how to resolve it.

   b. Internal consistency is extremely important. Making your app behave as universally as possible under similar circumstances will make you API's users more productive.

1. 在您的程序中出现的也到达框架内的情况下，例如参数为空、超出范围、无效、方法未实现或只是不受支持，那么您应该使用框架使用的相同异常。使用您的 API 的人会期望他们的行为方式如此（因为这就是其他一切行为的方式），因此将能够更好地从“开始”开始使用您的 API。

   2. 对于框架中不存在的新场景，您应该继续创建自己的异常类。我会说你应该更喜欢 Exception 作为你的基类，除非它们是提供你需要的服务的其他一些基本异常。一般来说，我认为“ApplicationException”之类的东西不会对你有多大帮助。当您开始定义自己的异常时，您应该记住以下几点：

   一种。例外的主要目的是用于人际交流。他们传达了关于发生了不应该发生的事情的信息。他们应该提供足够的信息来确定问题的原因并找出解决方法。

   湾 内部一致性非常重要。让您的应用在类似情况下的行为尽可能普遍，将使您的 API 用户更有效率。

As far as there being hard and fast rules about what you should and should not do... I wouldn't worry about that stuff. Instead I would just focus on identifying scenarios, finding the existing exception that fits those scenarios, and then carefully desining your own if an existing one doesn't exist.

至于你应该做什么和不应该做什么的硬性规定......我不会担心那些东西。相反，我只会专注于识别场景，找到适合这些场景的现有异常，然后在现有异常不存在的情况下仔细设计自己的异常。