Answers:
存在允许异常处理的异常，该异常处理可以避免崩溃，但更一般而言，可以防止意外或不可预测的系统行为。例如，如果我的程序与数据库的连接超时，通常不会使系统崩溃，但是如果我依赖于数据库中的数据，则异常可以使我以不同于常规的方式对待这种无数据的情况。
假设默认情况下，我的程序基于数据库返回的内容显示数据页面-废话，我没有数据。无需呈现混乱的视图或继续进行可能无效的操作，我可以捕捉到该异常并回到另一个数据库，从本地数据中读取，询问用户数据或以其他方式使用户或系统返回安全状态（大概是一个状态）。那不会立即导致相同的异常！）
另外，在用户输入可能是问题原因/解决方案的系统中，异常可以使用户知道有关问题的详细且有用的信息。您可以告诉用户一些有用或至少可以理解的内容，例如“无法连接到资源B”，而不是太常见的“在...处发生未处理的异常”或“直接从SQL发出令人生畏的错误消息”。
例外的重点应该是告知用户特殊情况。如果系统出了问题，程序应该知道并被允许*适当地处理它。
就是说，不，不存在防止系统“崩溃”的异常。一个例外是让我知道有问题。我如何确定可以确定系统是否“崩溃”。
还请注意，异常不必像您所说的那样终止应用程序。异常可以由程序员处理，并可以对用户纠正或转变为有意义的错误。
*使用检查异常（被强制捕获的异常）有点痛。一些（也许是大多数）开发人员发现，强制异常处理麻烦，不需要并且只是不好的做法。
异常允许通过从错误处理程序中拆分错误位置来进行现代错误处理。有时这也用于流量控制。
未处理的异常会终止程序。但是这些与以前的例外没有什么不同，只是一个懒惰的程序员忘记了在每个路径中都包含适当的错误处理程序，使得它们对于最终用户是可见的。我认为异常终止的程序与任何其他意外结束一样崩溃。
操作系统非常适合清理崩溃的进程，无论它们如何崩溃，因此，除了终止发生故障的进程并释放其资源之外，异常不会为操作系统增加安全性。
存在将正常程序流（程序设计为做什么）与错误处理流分开的示例（程序如何从异常情况中恢复。
这使代码更清晰，更易于维护。
考虑两个代码段：
try:
do1() # this is obvoiusly a normal
do2() # program flow
except:
oups() # this is exception handling code
与此相比：
if foo():
thing1() # is this part of normal program flow?
else:
thing2() # or maybe this one? Or both? When?
当然，可以通过以下方式使用异常处理来防止程序崩溃：
try { // very bad code
my();
whole();
ugly();
application();
here();
} catch (Throwable t) {
// pretend it's ok
}
但这不是现代编程语言中出现例外的原因。
您也可以使用while和break替代的if，但这不是什么while和break是。