如果用户名无效或密码不正确，这不是一个例外。这些都是在正常操作流程中应该预料到的事情。异常不属于正常程序操作的一部分，而且相当罕见。

我不喜欢使用异常，因为仅仅通过查看调用就无法判断一个方法是否引发了异常。这就是为什么只有当你不能以一种体面的方式处理这种情况时才应该使用异常(比如“内存不足”或“电脑着火了”)。

我个人的指导方针是:当发现当前代码块的基本假设为假时抛出异常。

例1:假设我有一个函数，它应该检查任意类，如果该类继承自List<>，则返回true。这个函数问一个问题:“这个对象是List的后代吗?”这个函数永远不会抛出异常，因为它的操作中没有灰色地带——每个单独的类要么继承了List<>，要么继承了List<>，所以答案总是“是”或“否”。

Example 2: say I have another function which examines a List<> and returns true if its length is more than 50, and false if the length is less. This function asks the question, "Does this list have more than 50 items?" But this question makes an assumption - it assumes that the object it is given is a list. If I hand it a NULL, then that assumption is false. In that case, if the function returns either true or false, then it is breaking its own rules. The function cannot return anything and claim that it answered the question correctly. So it doesn't return - it throws an exception.

这与“负载问题”逻辑谬误相当。每个函数都问一个问题。如果给出的输入使该问题成为谬误，则抛出异常。对于返回void的函数，这条线很难画出来，但底线是:如果函数对其输入的假设违反了，它应该抛出异常，而不是正常返回。

这个等式的另一方面是:如果你发现你的函数经常抛出异常，那么你可能需要改进它们的假设。

异常与返回错误代码参数应该是关于流控制的，而不是哲学(错误有多“异常”):

void f1() throws ExceptionType1, ExceptionType2 {}

void catchFunction() {
  try{
    while(someCondition){
      try{
        f1(); 
      }catch(ExceptionType2 e2){
        //do something, don't break the loop
      }
    }
  }catch(ExceptionType1 e1){
    //break the loop, do something else
  }

}

安全性与您的示例混为一谈:您不应该告诉攻击者用户名存在，但密码是错误的。这是你不需要分享的额外信息。只要说“用户名或密码不正确”。

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

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

for me Exception should be thrown when a required technical or business rule fails. for instance if a car entity is associated with array of 4 tires ... if one tire or more are null ... an exception should be Fired "NotEnoughTiresException" , cuz it can be caught at different level of the system and have a significant meaning through logging. besides if we just try to flow control the null and prevent the instanciation of the car . we might never never find the source of the problem , cuz the tire isn't supposed to be null in the first place .