處理C++異常問題會在語言級別上遇到少許隱含限制，但在某些情況下，您可以繞過它們。學習各種利用異常的方法，您就可以生產更可靠的應用程序，本文就對於大多數用戶頭疼的C++異常問題進行詳細的剖析與介紹。
在C++中，無論何時在處理程序內捕獲一個異常，關於該異常來源的信息都是不為人知的。異常的具體來源可以提供許多更好地處理該異常的重要信息，或者提供一些可以附加到錯誤日志的信息，以便以後進行分析。
為了解決這一問題，可以在拋出異常語句期間，在異常對象的構造函數中生成一個堆棧跟蹤。ExceptionTracer是示范這種行為的一個類。
在異常對象構造函數中生成一個堆棧跟蹤：
- private:
- class SingleTonTranslator
- {
- public:
- SingleTonTranslator()
- {
- signal(SignalExceptionClass::GetSignalNumber(),
- SignalHandler);
- }
- static void SignalHandler(int)
- {
- throw SignalExceptionClass();
- }
- };
- public:
- SignalTranslator()
- {
- static SingleTonTranslator s_objTranslator;
- }
- };
- // An example for SIGSEGV
- class SegmentationFault : public ExceptionTracer, public
- exception
- {
- public:
- static int GetSignalNumber() {return SIGSEGV;}
- };
- SignalTranslator<SegmentationFault>
- g_objSegmentationFaultTranslator;
- // An example for SIGFPE
- class FloatingPointException : public ExceptionTracer, public
- exception
- {
- public:
- static int GetSignalNumber() {return SIGFPE;}
- };
每當進程執行一個令人討厭的動作，以致於 Linux? 內核發出一個信號時，該信號都必須被處理。信號處理程序通常會釋放一些重要資源並終止應用程序。
在這種情況下，堆棧上的所有對象實例都處於未破壞狀態。另一方面，如果這些信號被轉換成C++ 異常，那麼您可以優雅地調用其構造函數，並安排多層 catch 塊，以便更好地處理這些信號。
定義的 SignalExceptionClass，提供了表示內核可能發出信號的C++異常問題的抽象。SignalTranslator 是一個基於 SignalExceptionClass 的模板類，它通常用來實現到 C++ 異常的轉換。
在任何瞬間，只能有一個信號處理程序處理一個活動進程的一個信號。因此，SignalTranslator 采用了singleton 設計模式。整體概念通過用於 SIGSEGV 的 SegmentationFault 類和用於 SIGFPE 的FloatingPointException 類得到了展示。
在全局靜態全局）變量的構造和析構期間，每個 ANSI C++ 都捕獲到異常是不可能的。因此，ANSI C++ 不建議在那些其實例可能被定義為全局實例靜態全局實例）的類的構造函數和析構函數中拋出異常。
換一種說法就是永遠都不要為那些其構造函數和析構函數可能拋出異常的類定義全局靜態全局）實例。不過，如果假定有一個特定編譯器和一個特定系統，那麼可能可以這樣做，幸運的是，對於Linux 上的 GCC，恰好是這種情況。
使用 ExceptionHandler 類可以展示這一點，該類也采用了 singleton 設計模式。其構造函數注冊了一個未捕獲的處理程序。因為每次只能有一個未捕獲的處理程序處理一個活動進程。
構造函數應該只被調用一次，因此要采用 singleton 模式。應該在定義有問題的實際全局靜態全局）變量之前定義 ExceptionHandler 的全局靜態全局）實例。
