有没有一些情况下，抛出可以避免的错误是一个好主意呢？
我特别考虑了 DivideByZeroException 和 ArgumentNullException。
例如：
double numerator = 10;
double denominator = getDenominator();
if( denominator == 0 ){
throw new DivideByZeroException("You can't divide by Zero!");
}
有什么原因会导致出现这样的错误吗？
注意：我不是在谈论捕获这些错误，而是特别想知道是否有正当理由抛出它们。
再次强调：
我知道在我给你的例子中，最好处理这个错误。也许问题应该重新表述。是否有任何理由在此处抛出这些错误，而不是处理它们。
假设你编写了一个用于处理不能适应Int64的非常大整数的库，那么你可能想要在你编写的除法算法中抛出DivideByZeroException异常。
.NET运行时已经非常擅长抛出这些异常了。它们也非常描述出问题所在，您无法为异常消息添加任何有价值的注释。 "您不能将零作为除数" 毫无价值。
但是，通过筛查客户端代码传递的值，您可以避免许多此类异常。如果客户端代码传递了 null，则应使用带有参数名称的ArgumentNullException；如果传递了可能会导致 DivideByZero 问题的内容，则应使用ArgumentException。
LiteralErrorMsg1.Text = ex.Message。另一种情况是本地化。您可能还希望以用户的语言显示错误消息。 - ArmstrongestArgumentNullException，而不是 NullReferenceException。 - Armstrongest这样做绝对有原因，就像大多数异常抛出问题一样，你必须考虑作为一个团队中的开发者。你所编写的代码可能是另一个系统的一部分，也可能是一个库或组件。
如果你编写了一个数学库，并且有一个名为Divide(int a, int b)的函数用于除法运算，如果有人想使用你的方法并传入0，那么你会希望抛出一个异常，以便他们作为开发者知道他们犯了错误。
如果你不抛出异常，就会在你的代码中引入漏洞。如果我使用了你的除法方法，并将值10和0放入其中，这将产生10/0，从而引发异常，唯一正确的答案是错误。如果你决定更改值，使其不会出现错误，或者返回0，那不是我期望的结果——我认为我的除法运算完美无缺，从未注意到问题。我可能会拿着这个0去进行其他计算，毫不知情地使用了错误的答案，因为10/0不是0。
您只应使用异常处理异常情况。
在这种情况下，看起来零将是无效的用户输入。您应该检查无效的用户输入并相应地处理在到达适当的异常点之前。
只要正确处理输入，就没有理由发生DivideByZeroException。如果您在验证输入后仍收到DivideByZeroException，则说明您有一个真正的问题（在这种情况下，异常是适当的）。
Debug.Assert(dispenser != null);
这样，您就可以验证代码是否正确运行，并在不用大量无用、冗余检查的情况下及早捕捉错误，而不会减缓发布代码的速度。
"在框架中，异常被用于处理硬错误和逻辑错误。起初，采用异常处理作为报告所有功能性失败的手段可能会有些困难。然而，设计框架的所有公共方法以通过抛出异常来报告方法失败是非常重要的。"
标题有点误导，它不是关于抛出（特殊的）DivideByZeroException，而是关于这个问题：
在验证用户输入时，我应该使用异常吗？
这可能已经被问过了。我的看法是：不要，只需使用让您可以使用错误代码或布尔值处理此问题的流程。
但是，在应用程序的更深层中验证“数据”时，抛出异常通常是正确的做法。
ArgumentNullException。 - Armstrongest我想不出有什么例外情况。我会直接编写程序来避免异常情况的发生。异常处理可能会很耗费资源，所以如果你可以通过防御性编程来避免异常情况，那就这样做，而不是抛出异常。
至少这是我的高级开发人员在很久以前当我试图捕获DivideByZeroException时告诉我的。