java – 为什么android.database.SQLException未经检查?

这可能不适合SO,因为它不是真正的编码问题,但我找不到令人满意的答案,我相信SO社区可以.因此,根据定义,android.database.SQLException和java.sql.SQLException共享大致相同的应用程序范围,即在访问/修改数据库时提供...

这可能不适合SO,因为它不是真正的编码问题,但我找不到令人满意的答案,我相信SO社区可以.

因此,根据定义,android.database.SQLException和java.sql.SQLException共享大致相同的应用程序范围,即在访问/修改数据库时提供有关错误的信息.虽然我已经读过某个检查异常是“out”的地方,但我真的很喜欢编译器提醒你在使用throws关键字检查异常时处理异常的事实.不幸的是,这不适用于未经检查的异常.

我的问题是:
为什么Google在检查java.sql.SQLException时取消选中android.database.SQLException?我错过了什么吗?他们的差异是否超出我的想象?

解决方法:

选中或取消选中例外之间的选择总是有点主观:

>如果异常表示存在错误,或某些“可能无法恢复”的错误,则应选择未经检查的异常.
>如果异常表示“可能可恢复”的故障,则检查异常是合适的.

在这种情况下,如果存在许多子类的一般异常,则更加困难.其中一些子类可能是错误,或者它们可以恢复.在这一点上,设计者必须对异常的所有已知/预测的子类型的不同情况的相对可能性做出价值判断.

在这种情况下,Sun和Google工程师得出了不同的结论.但请注意,Google工程师具有Sun工程师所没有的巨大优势.他们可以查看Java设计,并根据已检查的SQLException自行判断它的工作情况.

Though I’ve read somewhere that checked exceptions are “out” …

有很多开发人员希望不检查所有Java异常,这样他们就不必被迫处理它们.还有很多其他的开发人员仍然认为Java使用经过检查的异常就做对了……即使有少数情况下做出了错误的选择(事后看来).

这是值得商榷的.

Am I missing something? Do they differ more than I think?

并不是的.这两个异常层次结构的用途几乎相同……尽管javadoc类描述存在差异.

本文标题为:java – 为什么android.database.SQLException未经检查?

基础教程推荐