纠正编码错误篇 （3）Cursor、Exception 常见警告及解决办法

前言

这一篇接着讲讲一些比较有意思的黄色警告（Warning），仔细的想了一下，也就想起来了cursor，Exception是最近才遇到的，所以也顺便说一下。

对于系统的一般的警告提示，比如，局部变量不要赋值啊 ，if条件恒等啊，方法已经过时之类的，这里就不说了。

正文

Cursor

Cursor是光标的意思，主要就是应用在数据库中，我们去查询一条或多条记录，会返回查询结果的光标，通过对这个光标进行循环，得到所有的查询结果。

我遇到的Cursor主要有两个非常重要的警告（Warning）：

1、可能出现空指针异常的警告

Method invocation ‘moveToNext’ may produce ‘java.lang.NullPointerException’ less…
This inspection analyzes method control and data flow to report possible conditions that are always true or false, expressions whose value is statically proven to be constant, and situations that can lead to nullability contract violations.
Variables, method parameters and return values marked as @Nullable or @NotNull are treated as nullable (or not-null, respectively) and used during the analysis to check nullability contracts, e.g. report NullPointerException (NPE) errors that might be produced.

好长的英文，虽然我能看懂，但是组织语言就有点费劲了，大概的意思就是在某些情况下，返回的Cursor可能是空的，建议我们用一些 @Nullable 或者 @NotNull 注解来检查是否可以为空，也就是这里可能为空，你看着办吧。

当时我们不能这么任性，都空指针了肯定是要崩溃的，为了增强程序的健壮性，在外层加上if(cursor != null) 就OK了。

2、Cursor没有被回收

This Cursor should be freed up after use with #close() less… (⌘F1)
Many resources, such as TypedArrays, VelocityTrackers, etc., should be recycled (with a recycle() call) after use. This lint check looks for missing recycle() calls

大概意思就是，这个Curor应该在使用之后调用close（）方法释放自己。许多资源，比如TypeArrays，VelocityTrackers 等等，他们使用结束了之后了需要调用recycle（）来回收和释放。

当我们一开始接触Cursor和数据库的时候，都听过看过无数次Cursor必须要close（），再犯这个错误就有点尴尬了，如果是try-catch中，建议把Cursor的回收放在finally中。

例如：

        Cursor cursor = null;        try {            StringBuilder sql = new StringBuilder("select * from Student");            cursor = SqlUtil.getInstance().rawQuery(sql.toString(), null);            if (cursor != null) {                while (cursor.moveToNext()) {                ...                }            }        }        catch (Exception e) {            e.printStackTrace();        }        finally {            if (cursor != null) {                cursor.close();            }        }

Exception

Exception就是异常，也是我们最不愿意看到的东西，因为他的存在，不得不做很多意外的处理，否则程序就会变得不稳定。

我遇到的情况，不能算是一个问题，仅仅是一种建议，但是我觉得很有意义，所以贴了出来：

catch’ branch identical to ‘InstantiationException | IllegalAccessException’ branch less… (⌘F1)
Reports identical catch sections in try blocks under JDK 7. A quickfix is available to collapse the sections into a multi-catch section.
This inspection only reports if the project or module is configured to use a language level of 7.0 or higher.

上面的警告大概意思是：在 try的代码块中，相同的catch块结构在JDK 7 以下比把这些块进行折叠到一个（多catch块）中要更有效。这个检查只在project或者module被配置使用JDK 7 或者更高的时候报告。

上面的 多catch块 被我加粗了，括号是为了方便断句。直接看我的截图，所有的东西就都明白了：

之前的catch语句

修改完的catch 语句：

一目了然，就是通过 “|” 运算符号折叠成一个判断语句，这个符号有”或”的意思，我觉得在这里理解非常合适。

应该是java意识到了catch语句的臃肿，所以在JDK中开始建议这种模式来捕获异常，相信将来，java其他方面也会越来越简化。

总结

从这些小小的警告中，我可以感受到编辑器默默无闻的为我们做了很多的事情，这也是为什么换了编辑器，很多人都会突然懵逼，所以看到这些提示，我们应该把正确的编码格式变为自己的习惯，把之前自己的陋习和缺点慢慢改正，而不是视而不见，一下带过。

暂时想不起来还有什么比较有意思的警告，如果有我再补上，如果有问题或者我说的有问题的地方欢迎留言指正。