乙個讓人遺忘的角落 Exception（一）

很誘人的標題，今天不是給大家介紹，而是跟大家討論些問題。

在做開發的這幾年中，大大小小的專案也經歷了很多，但無論那個專案中，都沒有真正的對

exception

進行完整的處理。雖然我們在學

c#的時候，經常會看到此類的介紹，但我們真的學以致用了嗎？

先來看看什麼是

exception

的解釋是異常，每次當我們程式調式的時候，或多或少的會遇到它（如果你的程式沒有遇到過，那你是天才）。

richer

在它的書中，反覆的提到，

exception

是對原有介面的一種違背。一開始我反覆不能理解，當我真的去考慮這個問題，深入這個主題的時候，我才明白了，它就是一種違背，引數錯、物件空等等我們常見的異常，都是因為我們對介面的定義有違背了，所以系統才會丟擲異常。

例：var str = "int";

int i = convert.toint32(str);

這個轉換會丟擲乙個異常出來，雖然

convert.toint32(string str)

是乙個合法的方法，但是輸入的

str必須是能轉換成

int值的，否則就回丟擲異常。這是對它方法定義的一種違背。

exception

不等於error

錯誤的解釋很廣泛，可能包含了異常，但是

exception

不等於error

的稍微簡單的介紹了一下異常，我想很多開發者一定對它非常熟悉了，但是真正對它的處理，我們做的並不好，很多人認為原有的系統異常已經足夠我們去尋找

bug了，我們只需要測試到位就可以了，但這是錯誤的思想，這也是可怕的思想，因為你不知道何時何地何處會丟擲乙個你不知道的異常，

win form

應用程式遇到了異常是非常可怕的，如果沒有處理，就會直接關閉應用程式，在我們

中，雖然

會對我們未處理的異常封裝，丟擲乙個

unhandlingexception

，對你要知道，你的**可是面對著不同的使用者，他們看到如此結果會如何呢？有人會說，我用錯誤頁面來包裝一下，這樣看上去是友好化的。沒錯，這是乙個解決方案，可你想過嗎？你要如何去知道這些

exception

呢？除非你的**人員遇到了，會及時通知你，但如果是客戶遇到呢？

我們不能守株待兔，我們是合格的程式設計師，我們的**是我們的孩子，我們必須給他最好的，包括他生病，我們就得馬上給他醫治，如果沒有生病，我們也必須打疫苗、提高抵抗力，也要及時想好應對方案，以免到時候會手忙腳亂。所以我們必須要有一套好的解決機制，才能應對各種突發事件。

真正完美的解決方案有嗎？我可以很肯定的告訴你，沒有。無論是開發何種應用程式，你的開發人員、環境、程式設計習慣、開發流程都會影響到這一套解決方案，如何解決，我的觀點是：從人開始。

**是死的，人是活的，我們必須時刻的意識到，我們是為創造程式而生的，不是為解決工作而做的，程式的美，是人之美，程式之

bug，乃人之

bug，乙個程式的好壞，其實就能看出乙個人的思維。應用程式發生異常，不代表是開發者的無能，這或許是乙個好的體驗機會，讓你更好的能學習到解決之道。

在處理exception

的時候，我們需要注意幾點，大家可以看另外一篇

"設計異常解決方案的幾點注意事項

"，這是最近看到一本書中介紹的，這是網上找來的中文版，非常好的。這些規範很大程度上讓我們能處理很多

exception

了，但是，還是那句話，從人開始，開發者的應用、開發者的思維都是很重要的，乙個公司統一的技術規範，是非常有必要的，在其他**中，你可以隨意，但是在處理異常的時候，你必須按照這個規範來，因為他真的非常重要而又非常容易忽視的，每個公司都應該對其進行一定的培訓，**的

review

，都是必不可少的。

單元測試

單元測試雖然也是一種解決方案，但並不是每個單元測試都會解決你系統中的

bug。

說了這麼多，其實我想讓大家了解異常的重要性，也讓大家在開發過程中，能盡量想到這些，以免造成不可設想的後果。

後續我會給大家帶來一定的解決方案，結合這幾年的經驗，開發一套通用的

exceptionhandling

乙個讓人遺忘的角落 Exception（一）

乙個讓人遺忘的角落 Exception（一）

乙個讓人遺忘的角落 Exception（二）

CSDN，乙個可能即將被遺忘的角落

乙個讓人遺忘的角落 Exception（一）

乙個讓人遺忘的角落 Exception（一）

乙個讓人遺忘的角落 Exception（二）

CSDN，乙個可能即將被遺忘的角落

相關推薦