很誘人的標題，今天不是給你們介紹，而是跟你們討論些問題。html
在作開發的這幾年中，大大小小的項目也經歷了不少，但不管那個項目中，都沒有真正的對Exception進行完整的處理。雖然咱們在學C#的時候，常常會看到此類的介紹，但咱們真的學以至用了嗎？程序員
先來看看什麼是Exception 編程
Exception的解釋是異常，每次當咱們程序調式的時候，或多或少的會遇到它（若是你的程序沒有遇到過，那你是天才）。Richer在它的書中，反覆的提到，Exception是對原有接口的一種違背。一開始我反覆不能理解，當我真的去考慮這個問題，深刻這個主題的時候，我才明白了，它就是一種違背，參數錯、對象空等等咱們常見的異常，都是由於咱們對接口的定義有違背了，因此係統纔會拋出異常。post
例：單元測試
var str = "int"; 學習
int i = Convert.ToInt32(str); 測試
這個轉換會拋出一個異常出來，雖然Convert.ToInt32(string str)是一個合法的方法，可是輸入的str必須是能轉換成Int值的，不然就回拋出異常。這是對它方法定義的一種違背。網站
Exception 不等於 Errorspa
錯誤的解釋很普遍，可能包含了異常，可是Exception 不等於 Error 的設計
稍微簡單的介紹了一下異常，我想不少開發者必定對它很是熟悉了，可是真正對它的處理，咱們作的並很差，不少人認爲原有的系統異常已經足夠咱們去尋找bug了，咱們只須要測試到位就能夠了，但這是錯誤的思想，這也是可怕的思想，由於你不知道什麼時候何地何處會拋出一個你不知道的異常，Win Form應用程序遇到了異常是很是可怕的，若是沒有處理，就會直接關閉應用程序，在咱們Web Application中，雖然HttpApplication會對咱們未處理的異常封裝，拋出一個UnhandlingException，對你要知道，你的網站但是面對着不一樣的用戶，他們看到如此結果會如何呢？有人會說，我用錯誤頁面來包裝一下，這樣看上去是友好化的。沒錯，這是一個解決方案，可你想過嗎？你要如何去知道這些Exception呢？除非你的網站人員遇到了，會及時通知你，但若是是客戶遇到呢？
咱們不能守株待兔，咱們是合格的程序員，咱們的代碼是咱們的孩子，咱們必須給他最好的，包括他生病，咱們就得立刻給他醫治，若是沒有生病，咱們也必須打疫苗、提升抵抗力，也要及時想好應對方案，以避免到時候會手忙腳亂。因此咱們必需要有一套好的解決機制，才能應對各類突發事件。
真正完美的解決方案有嗎？我能夠很確定的告訴你，沒有。不管是開發何種應用程序，你的開發人員、環境、編程習慣、開發流程都會影響到這一套解決方案，如何解決，個人觀點是：從人開始。
代碼是死的，人是活的，咱們必須時刻的意識到，咱們是爲創造程序而生的，不是爲解決工做而作的，程序的美，是人之美，程序之bug，乃人之bug，一個程序的好壞，其實就能看出一我的的思惟。應用程序發生異常，不表明是開發者的無能，這或許是一個好的體驗機會，讓你更好的能學習到解決之道。
在處理Exception的時候，咱們須要注意幾點，你們能夠看另一篇"設計異常解決方案的幾點注意事項"，這是最近看到一本書中介紹的，這是網上找來的中文版，很是好的。這些規範很大程度上讓咱們能處理不少Exception了，可是，仍是那句話，從人開始，開發者的應用、開發者的思惟都是很重要的，一個公司統一的技術規範，是很是有必要的，在其餘代碼中，你能夠隨意，可是在處理異常的時候，你必須按照這個規範來，由於他真的很是重要而又很是容易忽視的，每一個公司都應該對其進行必定的培訓，代碼的Review，都是必不可少的。
單元測試
單元測試雖然也是一種解決方案，但並非每一個單元測試都會解決你係統中的Bug。
說了這麼多，其實我想讓你們瞭解異常的重要性，也讓你們在開發過程當中，能儘可能想到這些，以避免形成不可設想的後果。
後續我會給你們帶來必定的解決方案，結合這幾年的經驗，開發一套通用的ExceptionHandling，固然這還須要你們對個人支持：P