在 Blackberry Java 中捕获 Throwable：好主意吗？
我经常在 Blackberry 文档中看到 Throwable 的 catch 子句，例如 网络 API 文档。我的感觉是，这在 Java 中通常不是一个好的做法。
黑莓编程中有这个原因吗？
它与堆栈跟踪生成有关吗对于可抛出的？
I often see catch clauses for Throwable in Blackberry documentation, such as the Network API docs. My sense is that this is not generally a good practice in Java.
Is there a reason for this in Blackberry programming?
Does it have to do with stack trace generation for Throwables?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当您在 BlackBerry 应用程序中捕获 Throwable 时，它不仅会保留堆栈跟踪，还会将该堆栈跟踪保存在设备事件日志中。 应用程序本身无法获取堆栈跟踪，因此遗憾的是您无法自动收集堆栈跟踪。
要查看堆栈跟踪，请打开事件日志查看器。对于带有物理键盘的黑莓，按住“Alt”，然后按 LGLG 以调出事件日志。
When you catch Throwable in a BlackBerry app, not only does it preserve the stack trace, it saves that stack trace in the device event log. There is no way for an app to get a stack trace itself, so unfortunately you can't automatically collect stack traces.
To view the stack trace, you pull up the event log viewer. For blackberries with physical keyboards, hold 'Alt' and then press L G L G to bring up the event log.
阅读 java.lang.Error 的文档，它是 Throwable 的子类，您会看到捕获 Throwable 的问题。
它说：
例如，您最终可能会无意中捕获 VirtualMachineError，表明整个虚拟机处于损坏状态。将某些内容放入finally 块中以在损坏的VM 上运行似乎不是一个好主意。
Read the documentation for java.lang.Error, which is a subclass of Throwable, and you'll see the problem with catching Throwable.
It says:
For example, you could end up inadvertently catching a VirtualMachineError indicating the whole VM is in a broken state. Putting something in the finally block to run on broken VM doesn't seem like a good idea.
我不认为有什么特别的原因。看评论：
这意味着该示例是基本的。并且有一个错字和一个不好的做法。因此，如果可能的话，捕获特定的异常。
I don't think there's a special reason. See the comment:
It means the example is basic. And has a typo, and a bad practice. So catch specific exceptions if possible.
在 BB 平台上，如果 Throwable 被捕获，它会保留堆栈跟踪并通常将其呈现在屏幕上，在用户面前爆炸。对于用户体验来说不太好:(
当捕获异常（和扩展类）时，出于效率原因，堆栈跟踪将被丢弃。
On the BB platform, if Throwable is caught it preserves the stacktrace and usually renders it on the screen, blasting in the user's face. Not very good for UX :(
When Exception (and extended classes) are caught the stacktrace is thrown away for efficiency reasons.