Java 定义一个；ProbableBugException“；代码气味、偏执狂还是良好实践？

在我的Java代码中，我偶尔会遇到这样的情况：我必须从库函数中捕获一个已检查的异常，我很确定在我的用例中不会发生这种异常

此外，在编码时，我有时会注意到，我依赖于来自其他模块（我自己的模块）的某些输入来具有或不具有特定功能。例如，我可能希望字符串采用某种格式等。在这些情况下，我通常会进行验证步骤，尽管我自己控制发送输入的代码

目前，我正在开发一个非常复杂的产品，我希望它非常可靠。除此之外，我希望它能够从捕获的异常中收集信息，并自动提交错误报告因此，对于上述两种情况，我定义了一个（未选中的）“ProbableBugException”，它告诉我在传递输入数据的代码中犯了错误。

这是a）愚蠢、b）偏执还是c）良好的做法？这将是主观的，我会在维基上给出三个答案，这样我们就可以在不扭曲民意的情况下投票了

预计到达时间： 感谢Svend指出Java有断言，我没有意识到这一点。断言实际上与我的问题差不多，但我只从C中知道它们，从未在那里使用过它们。

这很愚蠢，因为：

• 异常应该更加具体，就像InvalidInputException一样
• 你应该更仔细地考虑输入端，如果你觉得你需要这种异常，它很可能是不稳定的

---

这是一种良好的做法，因为：
• 你可能有一个同事在输入端编码，而你们两个可能误解了对方
• 如果你犯了一个错误，修复它就变得微不足道了
• 在输入端是某种插件的情况下，它可以帮助插件开发人员（可能是外部的）提供正确的输入

---

我认为使用一个是你真正想要的（“可能是bug”）。
我总是期待意外的结果
我经常有这样的代码：（$div在我的代码中永远不会是0）

---

我总是保护自己不受我和其他人的伤害
好吧……“愚蠢”可能很严厉，但如果你控制输入，就使用断言。这就是他们的目的。至于来自库代码的检查异常，那么，您必须记住“这是您的错”。捕捉异常情况，报告它，然后深入研究，看看你做错了什么。好吧，在这种情况下，我对严酷性没什么意见。：-）当我使用Java时，我有一种过度工程化的倾向，这是很难克服的。谢谢，我不知道Java有它们。是的，这正是我想要的。assert的问题是默认情况下在运行时被禁用。虽然使用断言是一种很好的做法，但并不总是推荐使用断言，尤其是在库中，因为您可能永远不知道应用程序是否会启用断言。我不认为在这种情况下抛出特殊异常会被认为是愚蠢或偏执的。好吧，显式抛出AssertionError实际上等同于我的自定义异常，并且与启用的断言无关。如果库函数将我置于一个我从未预料到的catch块中，我也会发现“throw new AssertionError”比“assert false”更易读。您在这里不使用assert有什么特别的原因吗？

if( $div != 0 ) {
   $var = $var2 / $div;
} else {
    /*
     * It should never happen
     */   
    throw Exception( 'relevant message' );
}