在大多数情况下，我将使用异常检查代码中的条件，我想知道何时才是使用断言的适当时间？
例如，
Group group=null;
try{
group = service().getGroup("abc");
}catch(Exception e){
//I dont log error because I know whenever error occur mean group not found
}
if(group !=null)
{
//do something
}您能指出断言如何适合这里吗？我应该使用断言吗？
似乎我从不在生产代码中使用断言，而仅在单元测试中看到断言。我确实知道，在大多数情况下，我可以像上面那样使用异常来进行检查，但是我想知道“专业”地执行异常的适当方法。
Answers:
断言应用于检查不应发生的事情，而异常应用于检查可能发生的事情。
例如，一个函数可能会被0除，因此应使用异常，但可以使用一个断言来检查硬盘驱动器突然消失。
断言将阻止程序运行，但是异常将使程序继续运行。
请注意，这if(group != null)不是断言，而只是有条件的。
我会不高兴（列表可能不完整，并且太长了，无法放入评论中），我会说：
换句话说，异常处理应用程序的健壮性，而断言处理应用程序的正确性。
断言的编写成本很低，您几乎可以在任何地方使用它们，而我使用的是这样的经验法则：断言语句看起来越愚蠢，它就越有价值，并且嵌入的信息越多。在调试行为不正确的程序时，您一定会根据自己的经验检查更明显的故障可能性。然后，您将检查根本不会发生的问题：这正是断言有很大帮助并节省时间的时候。
作为基本规则：
java命令默认情况下会关闭所有断言。）您问题中的以下代码风格不好，可能有错误
try {
group = service().getGroup("abc");
} catch (Exception e) {
//i dont log error because i know whenever error occur mean group not found
}问题是您不知道异常意味着未找到该组。service()调用也有可能引发异常，或者它返回null后导致NullPointerException。
当您捕获“预期”异常时，您应该仅捕获预期的异常。通过捕获java.lang.Exception（尤其是不记录日志），您将更加难以诊断/调试问题，并可能使应用程序遭受更大的损害。
好吧，回到Microsoft时，建议是在公开提供的所有API中都抛出Exception，并在对内部代码所做的各种假设中使用Asserts。定义有点松散，但我想这取决于每个开发人员。
关于异常的用法，顾名思义，它们的用法应该是特殊的，因此对于上面显示的代码，如果不存在任何服务，则getGroup调用应返回null。仅当网络链接断开或类似情况时，才应发生异常。
我想得出的结论是，每个应用程序定义断言与异常的界限都需要由开发团队来负责。
根据此文档http://docs.oracle.com/javase/6/docs/technotes/guides/language/assert.html#design-faq-general，“ assert语句适用于非公共前置条件，后置条件和类不变式公共先决条件检查仍应通过检查内部方法来执行，这些方法会导致特别记录的异常，例如IllegalArgumentException和IllegalStateException。”
如果您想进一步了解前置条件，后置条件和类不变性，请查看以下文档：http : //docs.oracle.com/javase/6/docs/technotes/guides/language/assert.html#usage-conditions。它还包含断言用法的示例。
我承认你的问题让我有些困惑。当不满足断言条件时，将引发异常。令人困惑的是，这称为AssertionError。请注意，它是未经检查的，例如（在非常类似的情况下引发的）IllegalArgumentException。
因此在Java中使用断言
请参见以下链接的Sun文档的6.1.2节（断言与其他错误代码）。
http://www.oracle.com/technetwork/articles/javase/javapch06.pdf
该文档提供了有关何时使用断言的最佳建议。引用文档：
“一个好的经验法则是，对于异常情况，您应该使用断言。断言是处理和忘记您不希望遇到的条件或状态的最快方法。处理。”
不幸的是，断言可以被禁用。在生产中，当需要跟踪意外情况时，您需要获得所有帮助，因此断言会使其失去资格。