終于把《讓程序在崩潰時體面的退出》這個系列的6篇文章全部發表出來了。
這6篇文章分別是：
《讓程序在崩潰時體面的退出之Unhandled Exception》
《讓程序在崩潰時體面的退出之CallStack》
《讓程序在崩潰時體面的退出之Dump文件》
《讓程序在崩潰時體面的退出之SEH》
《讓程序在崩潰時體面的退出之SEH+Dump文件》
《讓程序在崩潰時體面的退出之終極解決方案（SEH+Dump+Unhandled Exception Filter）》
WINCE-如何通過map文件定位異常地址
對這些東西的研究起始于項目中一個Prototype的開發。這個Prototype就是給我們的產品加上Log信息。既然是Log信息，那么在應用程序崩潰的時候也要記錄發生了什么而導致程序崩潰，而且這個信息對于開發人員來說是非常重要的。為此，在網上搜索了大量的資料來看，英文的中文的，再加上MSDN和那本磚頭書《Windows via C/C++》，總算是把Windows下軟件開發中對致命異常的處理給搞清楚了。按照我以前的習慣，把學到的新知識從新梳理總結了一下，寫成了這6篇系列文章。
現在文章發表完了，這篇文章只是一個總結，而不是終結。因為在學習和寫文章的過程中，還有一些問題沒有徹底搞明白，比如SEH中的EXCEPTION_CONTINUE_EXECUTION和SEH與C++中的EH的混合使用。
SEH中的EXCEPTION_CONTINUE_EXECUTION
不管是MSDN還是《Windows via C/C++》，對SEH中的EXCEPTION_CONTINUE_EXECUTION解釋都一樣：Exception is dismissed. Continue execution at the point where the exception occurred.。也就是說返回到出現異常的地方重新執行。而且《Windows via C/C++》還專門寫了一個例子來說明?？墒俏野凑諘系睦訉懗鐾瑯拥拇a，執行的結果卻跟書上不一樣：首先，代碼執行結果并不是期望的那樣；其次，出現異常的那行代碼后面的代碼并沒有執行。在網上搜索了一通，得到的答案是：返回到出現異常的地方重新執行是返回到匯編指令的那個地方，而不是C++代碼的那一行，如果這個指令用到了寄存器內的內容，那么由于寄存器內容沒有被修改，所以執行結果依然是錯的。但是這只是解釋了第一問題，對于第二個問題依然沒有答案。如果有時間的話，我會繼續對這個問題進行研究。
SEH與C++中的EH的混合使用
SEH是結構化的，不支持面向對象。而C++中的try/catch又只能捕捉到預定義的異常。各有優缺點，要想捕捉到所有異常，就要2個都用。那么代碼的可讀性和可維護性就會很差。不過，有網友看到我的文章后告訴我了一篇文章的地址，那篇文章就是講怎么樣將SEH的異常轉換成C++中的異常。這是一個非常好的方法。有空的話，我也會對這方面進行一下研究。
|