一个经验法则是在您通常无法预测的情况下使用异常。例如数据库连接、磁盘上丢失的文件等。对于您可以预测的场景，例如用户试图使用错误的密码登录，您应该使用返回布尔值的函数，并知道如何优雅地处理这种情况。您不希望仅仅因为有人输入了密码错误而抛出异常，从而突然结束执行。

我想说，基本上每一个原教旨主义都会导致地狱。

您当然不希望以异常驱动流结束，但是完全避免异常也是一个坏主意。你必须在两种方法之间找到平衡。我不会为每种异常情况创建异常类型。这是没有成效的。

我通常更喜欢创建两种基本类型的异常，它们在整个系统中使用:LogicalException和TechnicalException。如果需要，可以通过子类型进一步区分这些类型，但通常不是没有必要。

技术异常指的是真正意想不到的异常，比如数据库服务器宕机，到web服务的连接抛出IOException等等。

另一方面，逻辑异常用于将不太严重的错误情况传播到上层(通常是一些验证结果)。

请注意，即使是逻辑异常也不是为了定期使用来控制程序流，而是为了突出显示流何时应该真正结束的情况。在Java中使用时，这两种异常类型都是RuntimeException子类，错误处理是高度面向方面的。

因此，在登录示例中，创建类似AuthenticationException的东西并通过枚举值(如UsernameNotExisting、PasswordMismatch等)来区分具体情况可能是明智的。这样就不会产生巨大的异常层次结构，并且可以将捕获块保持在可维护的级别。您还可以轻松地使用一些通用的异常处理机制，因为您已经对异常进行了分类，并且非常清楚要向用户传播什么以及如何传播。

我们的典型用法是，当用户输入无效时，在Web服务调用期间抛出LogicalException。异常被编组到SOAPFault详细信息，然后在客户机上再次被解组到异常，这将导致在某个web页面输入字段上显示验证错误，因为异常已正确映射到该字段。

这当然不是唯一的情况:您不需要点击web服务来抛出异常。你可以在任何特殊情况下自由地这样做(比如在你需要快速失败的情况下)——这都取决于你的判断。

以下是我的建议:

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

在我看来，如果某些事情可以用“友好、礼貌”的方式处理(这意味着如果我们可以“通过使用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异常)描述(这取决于您的编程经验)，则必须抛出异常。

抛出异常的经验法则非常简单。当你的代码进入UNRECOVERABLE INVALID状态时，你可以这样做。如果数据被泄露，或者您无法回溯到目前为止发生的处理，那么您必须终止它。你还能做什么呢?您的处理逻辑最终将在其他地方失败。如果你能以某种方式恢复，那么就这样做，不要抛出异常。

在你的特定情况下，如果你被迫做一些愚蠢的事情，比如接受提款，然后才检查用户/密码，你应该通过抛出一个异常来终止这个过程，通知发生了一些不好的事情，并防止进一步的损害。

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。解析并捕获异常。在您的情况下，您可能希望提供一些方法来检查用户名是否有效或密码是否正确，这样您的用户(或您)就不必进行大量异常处理。这将有望产生更易于阅读的代码和更好的性能。

最终，决定取决于是使用异常处理更有助于处理此类应用程序级错误，还是通过您自己的机制(如返回状态代码)更有帮助。我不认为哪个更好有一个严格的规则，但我会考虑:

Who's calling your code? Is this a public API of some sort or an internal library? What language are you using? If it's Java, for example, then throwing a (checked) exception puts an explicit burden on your caller to handle this error condition in some way, as opposed to a return status which could be ignored. That could be good or bad. How are other error conditions in the same application handled? Callers won't want to deal with a module that handles errors in an idiosyncratic way unlike anything else in the system. How many things can go wrong with the routine in question, and how would they be handled differently? Consider the difference between a series of catch blocks that handle different errors and a switch on an error code. Do you have structured information about the error you need to return? Throwing an exception gives you a better place to put this information than just returning a status.