---
# System prepended metadata

title: 例外處理(Exception)
tags: [ASP.NET]

---

[![hackmd-github-sync-badge](https://hackmd.io/Z0_rSOa6Toa3_P_iWqvUNg/badge)](https://hackmd.io/Z0_rSOa6Toa3_P_iWqvUNg)
###### tags: `ASP.NET`
# 例外處理(Exception)
#### 是一個流程控制的陳述式，可以用這些陳述式來增加程式的互動性，並且事先處理預期的錯誤，可以確保系統的可用性與可靠性，避免系統在意想不到的狀況下發生錯誤，甚至導致服務中斷或資料毀損。

:::success
**try：放入主要的程式碼**  
**throw：拋出錯誤訊息**  
**catch：如果有錯誤，則錯誤訊息會被傳到這個區塊，並且執行這個區塊的行為**  
**finally：不論有無錯誤最後這個區塊都會被執行**  
:::
:::info
例外類別  
- Exception 
- SystemException 
- ApplicationException 
- NullReferenceException 
- FileNotFoundException 
- SerializationException

註：所有的例外狀況都是延伸自 System.Exception
:::

:::spoiler 當你問使用例外處理?
:::info
故事大綱 :  
在2013 年4 月29 日，Teddy 看到一則新聞，大意是說對岸駭客可能會將入侵目標轉向台灣，對台灣國防、政治、經濟安全造成危害。記者電話訪問了某警察單位。
記者：對於對岸駭客可能會入侵台灣一事，警察單位有什麼因應之道？
警察：主要還是要看有沒有人報案，有人報案我們就會處理。
Teddy 內心獨白：靠……過來一點。「有人報案我們就會處理」是哪招，會不會太消極了一點？
專案經理：對於我們產品品質不佳、bug 很多一事，團隊有何因應之道？
開發人員：主要還是要看有沒有人回報bug，有人回報我們就會處理。
由使用者發現問題才來「報案」，使用者會留下軟體品質不良的印象，此時再來處理已經稍嫌太晚，而且成本也高出很多。
要提升使用者的滿意度，減低「辦案成本」，最好能夠把發現問題的時間點往前移到設計階段（design phase），讓程式能夠以例外的方式來「報案（回報問題）」，讓開發人員能夠在程式中處理這些異常狀況，以提高產品的品質。
:::

---

## 使用時機 :
#### 第一類的錯誤在開發者階段就應該除錯修改完成，因此例外處理真正要做的是修正第二類錯誤，捕捉使用者在操作上的錯誤，之後可以再把錯誤做相對應的處理。
* **第一類錯誤 : 拼寫錯誤、語法錯誤** ( 開發者階段錯誤 )
* **第二類錯誤 : 系統上錯誤、瀏覽器錯誤、資料庫連線異常、讀取檔案異常** ( 使用者操作或系統錯誤 )

---

## 例外有兩種情形 :
**1. 可恢復性 :**  
**==<font class="red">直接處理錯誤:</font>== 有些錯誤是可以直接處理的，例如第一次開啟檔案時，有可能檔案並不存在，這時候你在偵測到這個錯誤時，可以建立一個新的檔案。**  
**==<font class="red">嘗試重新操作:</font>== 有些錯誤是因為網路連線造成的錯誤，通常可以在一段時間後，使用嘗試重新操作來進行。**   
**2. 不可恢復性 :**  
**==<font class="red">傳播錯誤給你的客戶端:</font>== 如果你不知道如何處理這個錯誤情況，可以直接把這個錯誤傳播給你的客戶端。**  
**==<font class="red">不作任何處理:</font>== 某些錯誤並沒有辦法立即處理，或是根本也不是能處理的情況，所以用這個方式先記錄來追蹤。**












<font class="red"></font>

<style>
.red {
  color: #CE0000;
}
</style>


