前言#
這一篇接著講講一些比較有意思的黃色警告（Warning），仔細(xì)的想了一下，也就想起來了cursor，Exception是最近才遇到的，所以也順便說一下。
對于系統(tǒng)的一般的警告提示，比如，局部變量不要賦值啊 ，if條件恒等啊，方法已經(jīng)過時之類的，這里就不說了。
正文#
<h2>Cursor</h2>
Cursor是光標(biāo)的意思，主要就是應(yīng)用在數(shù)據(jù)庫中，我們?nèi)ゲ樵円粭l或多條記錄，會返回查詢結(jié)果的光標(biāo)，通過對這個光標(biāo)進(jìn)行循環(huán)，得到所有的查詢結(jié)果。
我遇到的Cursor主要有兩個非常重要的警告（Warning）：
1、可能出現(xiàn)空指針異常的警告
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.
好長的英文，雖然我能看懂，但是組織語言就有點(diǎn)費(fèi)勁了，大概的意思就是在某些情況下，返回的Cursor可能是空的，建議我們用一些 @Nullable 或者 @NotNull 注解來檢查是否可以為空，也就是這里可能為空，你看著辦吧。
當(dāng)時我們不能這么任性，都空指針了肯定是要崩潰的，為了增強(qiáng)程序的健壯性，在外層加上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應(yīng)該在使用之后調(diào)用close（）方法釋放自己。許多資源，比如TypeArrays，VelocityTrackers 等等，他們使用結(jié)束了之后了需要調(diào)用recycle（）來回收和釋放。
當(dāng)我們一開始接觸Cursor和數(shù)據(jù)庫的時候，都聽過看過無數(shù)次Cursor必須要close（），再犯這個錯誤就有點(diǎn)尷尬了，如果是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();
}
}
<h2>Exception</h2>
Exception就是異常，也是我們最不愿意看到的東西，因?yàn)樗拇嬖?，不得不做很多意外的處理，否則程序就會變得不穩(wěn)定。
我遇到的情況，不能算是一個問題，僅僅是一種建議，但是我覺得很有意義，所以貼了出來：
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塊結(jié)構(gòu)在JDK 7 以下比把這些塊進(jìn)行折疊到一個（<b>多catch塊</b>）中要更有效。這個檢查只在project或者module被配置使用JDK 7 或者更高的時候報告。
上面的 <b>多catch塊</b> 被我加粗了，括號是為了方便斷句。直接看我的截圖，所有的東西就都明白了：
之前的catch語句
修改完的catch 語句：
一目了然，就是通過 “|” 運(yùn)算符號折疊成一個判斷語句，這個符號有"或"的意思，我覺得在這里理解非常合適。
應(yīng)該是java意識到了catch語句的臃腫，所以在JDK中開始建議這種模式來捕獲異常，相信將來，java其他方面也會越來越簡化。
總結(jié)#
從這些小小的警告中，我可以感受到編輯器默默無聞的為我們做了很多的事情，這也是為什么換了編輯器，很多人都會突然懵逼，所以看到這些提示，我們應(yīng)該把正確的編碼格式變?yōu)樽约旱牧?xí)慣，把之前自己的陋習(xí)和缺點(diǎn)慢慢改正，而不是視而不見，一下帶過。
暫時想不起來還有什么比較有意思的警告，如果有我再補(bǔ)上，如果有問題或者我說的有問題的地方歡迎留言指正。
