安卓遇到未捕获的 Java 异常会直接崩溃，为什么要这么设计

[t4we]

既然代码都跑在消息循环里，为什么非 debug 版本的 app，系统不主动捕获异常，然后处理下一个消息？这样用户体验不是更好吗？

[haaro]

“系统主动捕获异常，然后处理下一个消息”会导致后续的逻辑出现更大更不可控的问题，有点类似连锁反应

[misaka19000]

防止异常被吃掉吧

[chendy]

开发者没处理的异常，系统也不知道该怎么处理
与其让 app 以未知的状态强行继续运行不如直接崩掉

[gamexg]

fail-fast

能编译时就编译时出错，
运行时发现错误就立刻出错，而不是把错误数据带到后面
方便排查问题

[unco020511]

关键系统不知道怎么运行了啊

[AoEiuV020]

方便排查 bug 吧，等继续执行直到下不去了，这个源头就很难追溯了，

[xylxAdai]

不快点崩掉，等这个异常没处理在几分钟之后因为这个异常崩了，你堆栈咋找到嘛。

[dqzcwxb]

因为你不关心会产生什么问题,你只是嫌麻烦

[chengyiqun]

那样我敢肯定会有一堆带着大量 bug 上线的 app.

[zongren]

其实应该优化一下，个别异常可以不崩

[silymore]

普通的 java 异步线程挂了还是正常跑啊

[Keyi]

App 用户体验不是 Android 来保证而是 App 来保证的吧

[WebKit]

这。无论起 java 还是 C 层的崩溃。。你可以自己拦截处理异常。

[xingda920813]

我觉得其实没有必要崩溃. 普通的 Java SE 和服务端的 Tomcat 都是这样, 一个线程抛未捕获的异常, 不会导致整个 JVM 结束. 一个请求异常, 那个请求会返回 500 错误, 但整个 Web 容器不会挂掉.

[ikas]

问题是..一旦出了异常,ui 线程中各种状态就会变得复杂..就跟为啥要限制 ui 使用单线程一样
关于消息循环,你也可以通过一个技巧来捕捉异常..但是即使你捕捉了异常..你会发现你能做得也很少..出错的 ui 部分就"卡住"了..这时候就需要复杂的来处理,,比如直接重建相关 ui..然后事情就各种复杂了...

//
new Handler(mainLooper).post(() -> {
while (true) {
try {
Looper.loop();
} catch (MainLoopExitException e) {
running = false;
return;
} catch (Throwable e) {
//处理逻辑
}
}
});
//github 其实是有这样的写好的异常处理的.已经带了 ui 部分的处理.不过我忘记了是啥了