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

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

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

我的小指南很大程度上受到了“代码完成”这本伟大的书的影响:

使用异常来通知不应该被忽略的事情。 如果错误可以在本地处理，就不要使用异常 确保异常与例程的其余部分处于相同的抽象级别。 异常应该留给真正的异常。

我同意japollock的说法当你不确定手术的结果时就放弃接受。调用api、访问文件系统、数据库调用等。任何时候你都要超越编程语言的“界限”。

我想补充一点，请随意抛出一个标准异常。除非你打算做一些“不同”的事情(忽略，电子邮件，日志，显示twitter鲸鱼图片之类的东西)，否则不要费心自定义异常。

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

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