我认为在Java中（以及可能是任何具有异常处理的语言），普遍认为应该尽量避免使用异常处理来实际处理业务逻辑。通常，如果预计某种情况应该发生，那么应该直接检查并更直接地处理它，而不是依靠异常处理来为您进行检查。例如，以下示例不被认为是良好的做法：
try{
_map.put(myKey, myValue);
} catch(NullPointerException e){
_map = new HashMap<String, String>();
}
相反，惰性初始化应该更像这样实现：
if(_map == null){
_map = new HashMap<String, String>();
}
_map.put(myKey, myValue);
当然，可能会有更复杂的逻辑，而不仅仅是处理延迟初始化。因此，考虑到这种类型的事情通常是不被赞同的...在何时、如果有时，依赖于异常发生以进行某些业务逻辑是一个好主意？可以说，任何时候使用这种方法的情况实际上都凸显了所使用的 API 的弱点吗？
_map 没有被初始化时，您最终得到的是一个空映射，丢弃了您正在尝试添加的条目），并且它使代码中充斥着大量无用的 try-catch 块，这些块很可能会隐藏真正的问题。再以您自己的例子为例，如果对 _map.add() 的调用由于某些原因而抛出 NullPointerException（与 _map 为 null 不同的其他原因），会发生什么？突然间，您正在默默地重新创建一个空映射而不是向其中添加条目。我相信我无需真正说明这可能会因意外状态导致代码中完全不相关的任何数量的错误...在C++中，抛出异常是一个比较昂贵的操作，在Java中则更加昂贵。仅从效率的角度考虑，避免显式检查并接受异常是毫无意义的。我想你可能能够在一些检查是否会抛出异常非常复杂或几乎不可能的罕见情况下进行辩解，但除此之外，我的答案是“几乎从不”。
这实际上是一个讨论性问题，答案取决于您的系统设计。
我的直觉总是一概而论地不使用异常，但我见过几个系统使用异常来实现业务错误。我个人觉得这很恶心，但我真的理解在你知道它失败后立即中断业务流程、处理失败（例如回滚你的工作单元）并将错误返回给调用者，可能还会添加一些信息的优点。
可能的一个缺点是，在多个不同的类中进行错误处理非常简单，因此从代码中推断出当进程失败时发生的事情的定义非常困难。
无论如何，这里没有单一的答案，您需要权衡两种方法，并有时将它们结合起来。
关于您的示例，我不认为在“良好”（设计良好）的情况下使用异常来控制流程有任何优势。
异常是对象的原因。Java语言的设计者将所有Throwable分为两种主要类型：已检查和未检查，也有其原因。
依赖于异常发生来触发某些业务逻辑是一个好主意吗？
是的。绝对是的。您应该阅读《Effective Java, Second Edition》的第9章。所有内容都在那里。清晰明了，等待着您的到来。
如果您正在处理实际上是业务逻辑的错误条件，那么使用异常是可以的。例如：
try{
// register new user
if(getUser(name) != null)
throw new MyAppException("Such user already exists");
//other registration steps......
}catch(MyAppException ex){
sendMessage(ex.getMessage());
}
if 块内调用 sendMessage()，从而避免出现异常呢？如果需要的话，可以添加 break、continue、return 或其他合适的流程控制语句。这样做也能使情况更加清晰明了。 - user
StopException来停止迭代。对于这个答案的评论提到了Python的哲学：“宁愿请求原谅，也不要先问过许可”。 - Adam Paynter