NullPointerException異常的原因及java異常??


 所謂空指針異常,是因為用空(null)去調用屬性或方法。   null表示沒有這個對象,既然沒有這個對象,那么去調用他的屬性和方法,就會報異常。   <--主要有以下幾種原因:   1、使用了未初始化的變量(雖然已經聲明)   2、使用了未初始化的對象(雖然已經聲明)   3、使用了關鍵字或已存在的類名作變量對象方法或類名。   當應用程序試圖在需要對象的地方使用 null 時,拋出該異常。   <--這種情況包括:   調用 null對象的實例方法。   訪問或修改null對象的字段。   將null作為一個數組,獲得其長度。   將null作為一個數組,訪問或修改其時間片。   將null作為Throwable值拋出。 (以上幾點看明白,然后再查看你的代碼,肯定能找出來)

 

空指針異常。

一般報java.lang.NullPointerException的原因有以下幾種: 1.字符串變量未初始化; 2. 接口類型的對象沒有用具體的類初始化,比如: 3. List lt; 會報錯 4. List lt = new ArrayList(); 則不會報錯了 5. 當一個對象的值為空時,你沒有判斷為空的情況。 你可以試着把下面的代碼前加一行代碼:

if(rb!=null);

String類型的對象可以做如下判斷

if(rb!==null&&!"".equals(rb)) ……

當然還可以多做一個判斷,是否不為空字符串

if(rb!==null&&!"".equals(rb.trim()))

 

JDK8發布以及多日了,今天,想體驗一下,安裝之后,試着導入原來的一個Project,結果報出兩個紅叉:
The type java.lang.CharSequence cannot be resolved. It is indirectly referenced from required .class files
The type java.util.Map$Entry cannot be resolved. It is indirectly referenced from required .class files
很不理解,原來好好的一個項目怎么就報錯了呢,網上搜了一下也沒找到解決方法,無奈,只有退回原來的JDK7,
然后一切都恢復正常了,很是不解!
-----------------------------------------------解決方案
eclipse+tomcat7+jdk1.6
上面報錯的方式我的解法方法是吧jre8換成6的就好了
選中項目-》右鍵-》build path ->找到add library -》選擇JRE System Liberary》進入界面選擇alternate jre ->在后面的installed jres..
里選擇jdk1.6的目錄上的jre -》ok 之后 清楚 構建下就好了

 --------------------------回憶一下java異常

異常機制概述

異常機制是指當程序出現錯誤后,程序如何處理。具體來說,異常機制提供了程序退出的安全通道。當出現錯誤后,程序執行的流程發生改變,程序的控制權轉移到異常處理器。

異常處理的流程

當程序中拋出一個異常后,程序從程序中導致異常的代碼處跳出,java虛擬機檢測尋找和try關鍵字匹配的處理該異常的catch塊,如果找到,將控制權交到catch塊中的代碼,然后繼續往下執行程序,try塊中發生異常的代碼不會被重新執行。如果沒有找到處理該異常的catch塊,在所有的finally塊代碼被執行和當前線程的所屬的ThreadGroup的uncaughtException方法被調用后,遇到異常的當前線程被中止。

異常的結構

異常的繼承結構:Throwable為基類,Error和Exception繼承Throwable,RuntimeException和IOException等繼承Exception。Error和RuntimeException及其子類成為未檢查異常(unchecked),其它異常成為已檢查異常(checked)。 

Error異常

Error表示程序在運行期間出現了十分嚴重、不可恢復的錯誤,在這種情況下應用程序只能中止運行,例如JAVA 虛擬機出現錯誤。Error是一種unchecked Exception,編譯器不會檢查Error是否被處理,在程序中不用捕獲Error類型的異常。一般情況下,在程序中也不應該拋出Error類型的異常。

RuntimeException異常

Exception異常包括RuntimeException異常和其他非RuntimeException的異常。
RuntimeException 是一種Unchecked Exception,即表示編譯器不會檢查程序是否對RuntimeException作了處理,在程序中不必捕獲RuntimException類型的異常,也不必在方法體聲明拋出RuntimeException類。RuntimeException發生的時候,表示程序中出現了編程錯誤,所以應該找出錯誤修改程序,而不是去捕獲RuntimeException。

Checked Exception異常

Checked Exception異常,這也是在編程中使用最多的Exception,所有繼承自Exception並且不是RuntimeException的異常都是checked Exception,上圖中的IOException和ClassNotFoundException。JAVA 語言規定必須對checked Exception作處理,編譯器會對此作檢查,要么在方法體中聲明拋出checked Exception,要么使用catch語句捕獲checked Exception進行處理,不然不能通過編譯。

在聲明方法時候拋出異常

語法:throws(略)
為什么要在聲明方法拋出異常?
方法是否拋出異常與方法返回值的類型一樣重要。假設方法拋出異常卻沒有聲明該方法將拋出異常,那么客戶程序員可以調用這個方法而且不用編寫處理異常的代碼。那么,一旦出現異常,那么這個異常就沒有合適的異常控制器來解決。
為什么拋出的異常一定是已檢查異常? 
RuntimeException與Error可以在任何代碼中產生,它們不需要由程序員顯示的拋出,一旦出現錯誤,那么相應的異常會被自動拋出。遇到Error,程序員一般是無能為力的;遇到RuntimeException,那么一定是程序存在邏輯錯誤,要對程序進行修改;只有已檢查異常才是程序員所關心的,程序應該且僅應該拋出或處理已檢查異常。而已檢查異常是由程序員拋出的,這分為兩種情況:客戶程序員調用會拋出異常的庫函數;客戶程序員自己使用throw語句拋出異常。
注意:
覆蓋父類某方法的子類方法不能拋出比父類方法更多的異常,所以,有時設計父類的方法時會聲明拋出異常,但實際的實現方法的代碼卻並不拋出異常,這樣做的目的就是為了方便子類方法覆蓋父類方法時可以拋出異常。

在方法中如何拋出異常

語法:throw(略)
拋出什么異常?
對於一個異常對象,真正有用的信息是異常的對象類型,而異常對象本身毫無意義。比如一個異常對象的類型是ClassCastException,那么這個類名就是唯一有用的信息。所以,在選擇拋出什么異常時,最關鍵的就是選擇異常的類名能夠明確說明異常情況的類。
異常對象通常有兩種構造函數:一種是無參數的構造函數;另一種是帶一個字符串的構造函數,這個字符串將作為這個異常對象除了類型名以外的額外說明。

為什么要創建自己的異常?

當Java內置的異常都不能明確的說明異常情況的時候,需要創建自己的異常。需要注意的是,唯一有用的就是類型名這個信息,所以不要在異常類的設計上花費精力。

throw和throws的區別

 

補充:throwChecked函數的另外一種寫法如下所示:

注意:此時在main函數里面throwChecked就不用try異常了。

應該在聲明方法拋出異常還是在方法中捕獲異常?

處理原則:捕捉並處理哪些知道如何處理的異常,而傳遞哪些不知道如何處理的異常

使用finally塊釋放資源

finally關鍵字保證無論程序使用任何方式離開try塊,finally中的語句都會被執行。在以下三種情況下會進入finally塊:
(1) try塊中的代碼正常執行完畢。
(2) 在try塊中拋出異常。
(3) 在try塊中執行return、break、continue。
因此,當你需要一個地方來執行在任何情況下都必須執行的代碼時,就可以將這些代碼放入finally塊中。當你的程序中使用了外界資源,如數據庫連接,文件等,必須將釋放這些資源的代碼寫入finally塊中。
必須注意的是:在finally塊中不能拋出異常。JAVA異常處理機制保證無論在任何情況下必須先執行finally塊然后再離開try塊,因此在try塊中發生異常的時候,JAVA虛擬機先轉到finally塊執行finally塊中的代碼,finally塊執行完畢后,再向外拋出異常。如果在finally塊中拋出異常,try塊捕捉的異常就不能拋出,外部捕捉到的異常就是finally塊中的異常信息,而try塊中發生的真正的異常堆棧信息則丟失了。
請看下面的代碼:

運行程序后,調用者得到的信息如下
java.lang.NullPointerException
at myPackage.MyClass.method1(methodl.java:266)
而不是我們期望得到的數據庫異常。這是因為這里的con是null的關系,在finally語句中拋出了NullPointerException,在finally塊中增加對con是否為null的判斷可以避免產生這種情況。

丟失的異常

請看下面的代碼:

上面method2的代碼中,try塊捕獲method1拋出的數據庫異常SQLException后,拋出了新的自定義異常MyException。這段代碼是否並沒有什么問題,但看一下控制台的輸出:
MyException:發生了數據庫異常:對象名稱'MyTable' 無效。
at MyClass.method2(MyClass.java:232)
at MyClass.method3(MyClass.java:255)
原始異常SQLException的信息丟失了,這里只能看到method2里面定義的MyException的堆棧情況;而method1中發生的數據庫異常的堆棧則看不到,如何排錯呢,只有在method1的代碼行中一行行去尋找數據庫操作語句了。
JDK的開發者們也意識到了這個情況,在JDK1.4.1中,Throwable類增加了兩個構造方法,public Throwable(Throwable cause)和public Throwable(String message,Throwable cause),在構造函數中傳入的原始異常堆棧信息將會在printStackTrace方法中打印出來。但對於還在使用JDK1.3的程序員,就只能自己實現打印原始異常堆棧信息的功能了。實現過程也很簡單,只需要在自定義的異常類中增加一個原始異常字段,在構造函數中傳入原始異常,然后重載printStackTrace方法,首先調用類中保存的原始異常的printStackTrace方法,然后再調用super.printStackTrace方法就可以打印出原始異常信息了。可以這樣定義前面代碼中出現的MyException類:


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM