乙個讓人遺忘的角落 Exception(二)

2022-01-16 01:32:41 字數 4559 閱讀 1127

"乙個被人遺忘的角落

--exception

(一)"

中,跟大家簡單介紹了一下

exception

,也使大家充分的了解了

exception

管理在乙個專案中的重要性,那如何在我們的專案中處理異常呢?因為我從事的是

web開發,所以我只跟大家討論

web的解決方案,

win的解決方式,還希望同大家一起**。

上一章中我們了解了異常發生的原因,同時也說了不存在沒有

bug的程式,任何**都會遇到各種各樣的問題,無論是大**還是小**都會存在,但大公司和小公司對待異常的態度全然不同,乙個是主動出擊,乙個是守株待兔,我們是好的開發者,我們不能坐以待斃,我們必須主動出擊。好了,廢話少說,切入主題。

現在**一般都採用多層開發,多層開發的時候,我們應該在**處理異常、在丟擲異常呢?微軟的意見是類庫的開發人員盡量不要處理異常,類庫的編寫應該按照正常的邏輯去編寫,當然也有例外,注意事項可以參見

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

",好的,按照規範,我們應該盡量在高層進行捕捉和處理,那我們該怎麼捕捉,捕捉後怎麼處理,捕捉哪些異常呢?雖然微軟提供了很多系統異常,但是這些異常只是負責丟擲相關的資訊,並沒有為記錄下來,或者出現高階異常的時候,及時通知我們,這樣的做法還是守株待兔,我們還是應該主動的對其進行處理。好在微軟讓我們可以自由的建立自定義的

exception

,最好是設定乙個自定義

exception

基類,讓你的其他自定義

exception

都繼承這個類,以便今後更好的擴充套件。丟擲異常其實是效能消耗很大的操作,但是

richer

教父說過,丟擲異常的效能和你程式的穩定性相比,就變得非常渺小了。所以我們還是偏向於穩定性。因為處理異常的效能消耗,只是在異常發生時才產生,所以效能方面的問題,我們可以忽略了。(或許這話比較拗口,但相比系統的效能,我更趨向於系統的穩定)

如何建立乙個自定義的

exception

不得不說微軟考慮的太周到了,要建立乙個自定義的

exception

是非常簡單的。開啟

vs,建立乙個專案,然後新增乙個類,在

namespace

範圍內,輸入

exception

,然後2

下tab,vs

就自定幫您建立乙個自定義的

exception

了。exception

的相關屬性和方法,可以參見

msdn

。不過自動建立的

exception

都是繼承

system

.exception

的,按照微軟當初的設想,自定義的異常應該繼承

(可笑的是,微軟自己都沒有遵守這個約定

)。我們設定這個作為我們的

exception

基類mybaseexception

。**片斷:

[global::system.serializable]

public mybaseexception(string message) : base(message)

public mybaseexception(string message, exception inner) : base(message, inner)

protected mybaseexception(

system.runtime.serialization.serializationinfo info,

system.runtime.serialization.streamingcontext context)

: base(info, context)

}這就是乙個標準的自定義

exception

了,至於其它的自定義

exception

,應該根據你的專案來進行相關的定義。

在進行其他定義之前,我們先來想想,我們捕捉這些

exception

之後我們需要做些什麼?我們需要知道異常發生的各種資訊,所以我們需要

log。

log能方便的讓我們查閱發生的異常及

log的異常資訊。

log有很多方式,大概的有以下幾種:

文字記錄

資料庫記錄

系統事件記錄(

trace

)第三方元件(

log4net

)這幾種方式各有利弊,可以根據專案的需求進行選擇,當然你也可以幾種方式合用,比如我們預設的是文字記錄方式,但是在建立

log時發生了

system

.ioexception時,

我們就必須選擇其他的方式進行

log。

log

方式

便捷性

查閱性

安全性

結合性

文字記錄

方便一般

資料庫記錄

一般方便

一般

系統事件記錄

複雜複雜

一般

第三方元件

複雜一般

一般

我列舉了幾種方式的利弊,大家可以有條件的選擇。如果你的專案中已經使用第三方元件記錄方式,那我建議您使用它。在我後面的解決方案中,我會利用前

2種比較常見的方式相結合。

log的目的是為我們開發者提供發生異常的時間、地點、人物、原因,所以我們必須盡可能的詳細地記錄,根據乙個

exception

獲取資訊的方法:

data

source

dates and times

datetime.now

source of exception

exception.source

type of exception

object.gettype

exception message

exception.message

current method

reflection.methodinfo.getcurrentmethod

machine name

environment.machinename or dns.gethostname

currentip

dns.gethostbyname("host").addresslist[0].address

call stack

exception.stacktrace or environment.stacktrace

os information

environment.osversion

current assembly

reflection.assembly.getexecutingassembly

root error cause

exception.getbaseexception

chained exception

exception.innerexception

assembly version

included in assemblyname.fullname

thread id

thread user

threading.thread.currentprincipal

我們可以根據上面的**,構建我們自己所需要的

log資訊。為了便捷的管理,我們應該採用同一格式,進行

log。這裡貼乙個我寫的資訊格式,以供參考:

public

static

class

exceptionlogformathelper

return sblog.tostring();

} }

你也可以根據你自己想要的資訊構建這麼乙個方法。

mybaseexception

乙個讓人遺忘的角落 Exception(一)

很誘人的標題,今天不是給大家介紹,而是跟大家討論些問題。在做開發的這幾年中,大大小小的專案也經歷了很多,但無論那個專案中,都沒有真正的對 exception 進行完整的處理。雖然我們在學 c 的時候,經常會看到此類的介紹,但我們真的學以致用了嗎?先來看看什麼是 exception exception...

乙個讓人遺忘的角落 Exception(一)

很誘人的標題,今天不是給大家介紹,而是跟大家討論些問題。在做開發的這幾年中,大大小小的專案也經歷了很多,但無論那個專案中,都沒有真正的對 exception 進行完整的處理。雖然我們在學 c 的時候,經常會看到此類的介紹,但我們真的學以致用了嗎?先來看看什麼是 exception exception...

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

csdn,創立於1999年,趕在網際網路興起的最好年頭,當時可以說是國內比較成功的 我也曾從它上面受益不少,但是現在不禁感嘆,它已不再是那個曾經讓人稱道的 雖然過了21個年頭,但是它並未實現大的提公升,反而有被後來者趕超的跡象。個人認為造成這一局面最大的問題在於其管理層的決策及戰略定位存在重大失誤,...