Java中如何避免空指針異常，這也是由初級(jí)程序員成長到中級(jí)程序員的時(shí)候經(jīng)常會(huì)遇到的問題。

程序員不知道或不信任正在使用的約定，并且小心的檢查著null。還有當(dāng)程序員寫代碼的時(shí)候，總是會(huì)依賴于通過返回空(NULL)來表明某些意義，因此需要調(diào)用者去檢查Null。

有兩種空指針的檢查場景：

• 期望的結(jié)果就是null。
• 期望的結(jié)果不是null。

第二種很簡單，可以通過用assert或者允許程序報(bào)錯(cuò)，例如拋出NullPointerException。Assertions是一個(gè)從Java1.4加進(jìn)來的高度未被利用的特性，語法是：

assert <condition>

或者

assert <condition> : <object>

condition是一個(gè)布爾表達(dá)式，object是一個(gè)對象(其toString()方法的輸出將會(huì)被包含在錯(cuò)誤里)。

校對注：我測試了下，JDK1.4及其以上，運(yùn)行前設(shè)置vm參數(shù)-ea

public static void main(String[] args) {String name = null;assert (name != null) : "name為空null";}
Exception in thread "main"; java.lang.AssertionError: 變量name為空nullat LogUtil.main(LogUtil.java:37)

如果condition為false的話，assert將會(huì)拋出一個(gè)Error(AssertionError)。默認(rèn)Java會(huì)忽略斷言你可以通過在JVM中傳入一個(gè)-ea參數(shù)來啟用斷言。

你可以為單獨(dú)的一個(gè)包或者類啟動(dòng)關(guān)閉assertions。這意味著你可以在開發(fā)和測試的時(shí)候通過斷言來驗(yàn)證代碼，在發(fā)布產(chǎn)品的時(shí)候關(guān)閉它，盡管我下面展示的測試中并沒有因?yàn)閍ssertions而損失性能。在這個(gè)代碼段中不用斷言也可以，因?yàn)樗麜?huì)運(yùn)行失敗的，就像加了斷言一樣。唯一的區(qū)別是有了斷言可能會(huì)發(fā)生的更快一些，更有意義，并且會(huì)附加一些額外的信息，而這可以幫助你弄明白失敗的原因。

第一種有一點(diǎn)棘手。如果你對不能控制正在調(diào)用的這段代碼，那你就卡住了。如果Null是一個(gè)合理的返回值，你就應(yīng)該檢查它。如果是你能夠控制的代碼，那就是個(gè)完全不同的故事情景了。盡量避免用NULL作為返回值。對于返回Collections的集合很容易，返回Empty(一個(gè)空集合或者數(shù)組)，而不是一直用null作為返回值。對于不是返回Collections的方法會(huì)有一點(diǎn)復(fù)雜。考慮下面這個(gè)例子：

public interface Action {
  void doSomething();}public interface Parser {
  Action findAction(String userInput);}

Parser采用用戶的輸入作為參數(shù)，然后做一些事情(例如模擬一個(gè)命令行)?，F(xiàn)在你可能會(huì)返回null，如果沒找到對應(yīng)輸入的動(dòng)作的話，這就導(dǎo)致了剛才說過的空指針檢查。

一個(gè)可選的解決方案是永遠(yuǎn)不要返回null,而是返回一個(gè)空對象

public class MyParser implements Parser {
  private static Action DO_NOTHING = new Action() {
    public void doSomething() { /* do nothing */ }
  };

  public Action findAction(String userInput) {
    // ...
    if ( /* we can't find any actions */ ) {
      return DO_NOTHING;
    }
  }}

比較這段代碼：

Parser parser = ParserFactory.getParser();if (parser == null) {
  // now what?
  // this would be an example of where null isn't (or shouldn't be) a valid response}Action action = parser.findAction(someInput);if (action == null) {
  // do nothing} else {
  action.doSomething();}

和這段：

ParserFactory.getParser().findAction(someInput).doSomething();

這是個(gè)更好的設(shè)計(jì)，因?yàn)樽銐蚝啙?，避免了多余的判斷?/p>

即便如此，或許比較合適的設(shè)計(jì)是：findAction()方法之惡杰拋出一個(gè)異常，其中包含一些有意義的錯(cuò)誤信息—–特別是在這個(gè)案例中你依賴于用戶的輸入。

讓findAction()方法拋出一個(gè)異常而不是簡單的產(chǎn)生一個(gè)沒有任何解釋的NullPointerException 要好得多。

try {
    ParserFactory.getParser().findAction(someInput).doSomething();} catch(ActionNotFoundException anfe) {
    userConsole.err(anfe.getMessage());}

或者你認(rèn)為try/catch 的機(jī)制太丑了，你的action應(yīng)該跟用戶提供一個(gè)反饋而不是什么都不做：

public Action findAction(final String userInput) {
    /* Code to return requested Action if found */
    return new Action() {
        public void doSomething() {
            userConsole.err("Action not found: " + userInput);
        }
    }}

補(bǔ)充：個(gè)人在做項(xiàng)目時(shí)，對NullPointerException的幾點(diǎn)總結(jié)，請網(wǎng)友拍磚?。?！多多提意見，

1.對于別人接口的返回對象要做非空判斷，因?yàn)槲覀儾磺宄@得的對象會(huì)不會(huì)為空，對于Collection Map 我一般會(huì)調(diào)用CollectionUtils MapUtils ,對于返回的String對象，我會(huì)調(diào)StringUtils.isNotEmpty()進(jìn)行非空判斷。他們中isNotEmpty不僅判斷了NULL 還判斷了空集合和空串。例如從數(shù)據(jù)中查詢的結(jié)果。工作流中返回的定價(jià)URL

2. 對于自己創(chuàng)建的對象，要留心對象進(jìn)行哪些操作，中間會(huì)不會(huì)造成對象為空，如果可能加非空判斷，尤其是對于集合的操作，很容易就報(bào)空指針?。?！所以每次對操作集合時(shí)，我都會(huì)非常的留心。

3. 對于前臺(tái)的領(lǐng)域?qū)ο笠浅５牧粜模驗(yàn)檫@些對象是框架創(chuàng)建的，假如我沒有在前臺(tái)的文本框內(nèi)輸入值，雖然提交時(shí)后臺(tái)獲得的是空串，但發(fā)生NullPointerException的概率很高。

4. 對于String 的操作盡量使用apache 的StringUtils類，與String相比這個(gè)是非常的安全。對于集合的操作使用apache的CollectionUtils 、MapUtils, 相比apache工具類的執(zhí)行效率也非常的高，比如StringUtils.split();

有人說過多的判斷會(huì)影響性能，我個(gè)人認(rèn)為這里的性能犧牲和系統(tǒng)的安全相比是微不足道的。

總結(jié)

到此這篇關(guān)于Java中空指針異常該如何避免的文章就介紹到這了,更多相關(guān)Java空指針異常內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論