我想说，对于什么时候使用异常并没有硬性规定。然而，使用或不使用它们有很好的理由:

使用异常的原因:

The code flow for the common case is clearer Can return complex error information as an object (although this can also be achieved using error "out" parameter passed by reference) Languages generally provide some facility for managing tidy cleanup in the event of the exception (try/finally in Java, using in C#, RAII in C++) In the event no exception is thrown, execution can sometimes be faster than checking return codes In Java, checked exceptions must be declared or caught (although this can be a reason against)

不使用异常的原因:

Sometimes it's overkill if the error handling is simple If exceptions are not documented or declared, they may be uncaught by calling code, which may be worse than if the the calling code just ignored a return code (application exit vs silent failure - which is worse may depend on the scenario) In C++, code that uses exceptions must be exception safe (even if you don't throw or catch them, but call a throwing function indirectly) In C++, it is hard to tell when a function might throw, therefore you must be paranoid about exception safety if you use them Throwing and catching exceptions is generally significantly more expensive compared to checking a return flag

一般来说，我更倾向于在Java中使用异常，而不是在c++或c#中，因为我认为异常，无论是否声明，都是函数正式接口的基本组成部分，因为更改异常保证可能会破坏调用代码。在Java IMO中使用它们的最大优势是，您知道调用者必须处理异常，这提高了正确行为的机会。

正因为如此，在任何语言中，我总是从一个公共类派生一层代码或API中的所有异常，这样调用的代码就总能保证捕获所有异常。另外，我认为在编写API或库时抛出特定于实现的异常类是不好的(即从较低的层包装异常，以便调用者接收到的异常在您的接口上下文中是可以理解的)。

注意，Java区分了一般异常和运行时异常，因为后者不需要声明。我只会使用运行时异常类，当您知道错误是由程序中的错误导致的。

以下是我的建议:

我不认为这总是一个抛出异常的好方法，因为它将花费更多的时间和内存来处理这样的异常。

在我看来，如果某些事情可以用“友好、礼貌”的方式处理(这意味着如果我们可以“通过使用if......或类似的东西来预测这样的错误)，我们应该避免使用“异常”，而只是返回一个像“false”这样的标志，用一个外部参数值告诉他/她详细的原因。

举个例子，我们可以这样创建一个类:

public class ValueReturnWithInfo<T>
{
   public T Value{get;private set;}
   public string errorMsg{get;private set;}
   public ValueReturnWithInfo(T value,string errmsg)
   {
      Value = value;
      errMsg = errmsg;
   }
}

我们可以使用这种“多值返回”类来代替错误，这似乎是处理异常问题的一种更好、更礼貌的方式。

但是，请注意，如果一些错误不能如此容易地用"if"......(例如FileIO异常)描述(这取决于您的编程经验)，则必须抛出异常。

抛出异常会导致堆栈unwind，这对性能有一定影响(承认，现代托管环境在这方面有所改进)。仍然在嵌套的情况下反复抛出和捕获异常是一个坏主意。

可能比这更重要的是，例外是针对特殊情况的。它们不应该用于普通的控制流，因为这会损害代码的可读性。

You may use a little bit generic exceptions for that conditions. For e.g. ArgumentException is meant to be used when anything goes wrong with the parameters to a method (with the exception of ArgumentNullException). Generally you would not need exceptions like LessThanZeroException, NotPrimeNumberException etc. Think of the user of your method. The number of the conditions that she will want to handle specifically is equal to the number of the type of the exceptions that your method needs to throw. This way, you can determine how detailed exceptions you will have.

顺便说一下，总是尝试为库的用户提供一些避免异常的方法。TryParse就是一个很好的例子，它的存在使你不必使用int。解析并捕获异常。在您的情况下，您可能希望提供一些方法来检查用户名是否有效或密码是否正确，这样您的用户(或您)就不必进行大量异常处理。这将有望产生更易于阅读的代码和更好的性能。

To my mind, the fundamental question should be whether one would expect that the caller would want to continue normal program flow if a condition occurs. If you don't know, either have separate doSomething and trySomething methods, where the former returns an error and the latter does not, or have a routine that accepts a parameter to indicate whether an exception should be thrown if it fails). Consider a class to send commands to a remote system and report responses. Certain commands (e.g. restart) will cause the remote system to send a response but then be non-responsive for a certain length of time. It is thus useful to be able to send a "ping" command and find out whether the remote system responds in a reasonable length of time without having to throw an exception if it doesn't (the caller would probably expect that the first few "ping" attempts would fail, but one would eventually work). On the other hand, if one has a sequence of commands like:

  exchange_command("open tempfile");
  exchange_command("write tempfile data {whatever}");
  exchange_command("write tempfile data {whatever}");
  exchange_command("write tempfile data {whatever}");
  exchange_command("write tempfile data {whatever}");
  exchange_command("close tempfile");
  exchange_command("copy tempfile to realfile");

人们会希望任何操作的失败都能中止整个序列。虽然可以检查每个操作以确保操作成功，但如果命令失败，让exchange_command()例程抛出异常会更有帮助。

实际上，在上面的场景中，有一个参数来选择一些失败处理模式可能会有所帮助:从不抛出异常，仅为通信错误抛出异常，或者在命令没有返回“成功”指示的任何情况下抛出异常。

其他人建议不应该使用异常，因为在正常流程中，如果用户输入错误，就会出现错误的登录。我不同意，我不明白其中的道理。与打开文件相比。如果该文件不存在或由于某种原因不可用，则框架将抛出异常。使用上述逻辑是微软的一个错误。他们应该返回一个错误代码。解析、webrequest等也一样。

I don't consider a bad login part of a normal flow, it's exceptional. Normally the user types the correct password, and the file does exist. The exceptional cases are exceptional and it's perfectly fine to use exceptions for those. Complicating your code by propagating return values through n levels up the stack is a waste of energy and will result in messy code. Do the simplest thing that could possibly work. Don't prematurely optimize by using error codes, exceptional stuff by definition rarely happens, and exceptions don't cost anything unless you throw them.