C++程式的例外處理技巧

處理 C++ 中的異常會在語言等級上碰到少許隱含限制，但在某些情況下，您可以繞過它們。學習各種利用異常的方法，您就可以生產更可靠的應用程式。 保留異常來源資訊 在C++中，無論何時在處理程序內捕捉一個異常，關於該異常來源的資訊都是不為人知的。異常的具體來源可以提供許多更好地處理該異常的重要信息，或者提供一些可以附加到錯誤日誌的信息，以便以後進行分析。 為了解決這個問題，可以在拋出異常語句期間，在異常物件的建構函式中產生一個堆疊追蹤。 ExceptionTracer是示範這種行為的一個類別。 清單1. 在異常物件建構子中產生一個堆疊追蹤// Sample PRogram:

// Compiler: gcc 3.2.3 20030502

// linux: Red Hat #include

// linux: Red Hat #include
.h> #include

#include using namespace std; /////////////////////////////// ////////////// class ExceptionTracer

{

public:

ExceptionTracer()

{

void * array[25];
{

void * array[25]; );

char ** symbols = backtrace_symbols(array, nSize);

　

for (int i = 0; i
} free(symbols);

}

}; 治理訊號 每當進程執行一個令人討厭的動作，以致於Linux? 核心發出一個訊號時，該訊號都必須被處理。訊號處理程序通常會釋放一些重要資源並終止應用程式。在這種情況下，堆疊上的所有物件實例都處於未破壞狀態。另一方面，假如這些訊號會轉換成C++ 異常，那麼您可以優雅地呼叫其建構函數，並安排多層 catch 區塊，以便更好地處理這些訊號。 清單 2 中定義的 SignalExceptionClass，提供了表示內核可能發出訊號的 C++ 異常的抽象。 SignalTranslator 是一個基於 SignalExceptionClass 的模板類，它通常用來實現到 C++ 異常的轉換。在任何瞬間，只能有一個訊號處理程序來處理一個活動進程的一個訊號。因此，SignalTranslator 採用了 singleton 設計模式。整體概念透過用於 SIGSEGV 的 SegmentationFault 類別和用於 SIGFPE 的FloatingPointException 類別得到了展示。 清單2. 將訊號轉換成異常



template class SignalTranslator

{

private:

classTonlator

private:

class {

signal(SignalExceptionClass ::GetSignalNumber(), 

SignalHandler);

} static void SignalHandler(int)

{

throw SignalExceptionClass();
{

static SingleTonTranslator s_objTranslator;

}

}; // An example for SIGSEGV

class SegmentationFault : public ExceptionTracer, public 
. ) {return SIGSEGV;}

} ; SignalTranslator 

g_objSegmentationFaultTranslator; // An example for SIGFPE

class FloatingPointException : public ExceptionTracer, public希
類alNumber() {return SIGFPE;}

}; SignalTranslator 

g_objFloatingPointExceptionTranslator;     治理建構子和斷層子構函中的異常 在全域（靜態全域）變數的建構和析構期間，每個ANSI C++ 都捕捉到異常是不可能的。因此，ANSI C++ 不建議在那些其實例可能被定義為全域實例（靜態全域實例）的類別的建構函式和析構函式中拋出例外狀況。換一種說法就是永遠不要為那些其建構子和析構函式可能拋出異常的類別定義全域（靜態全域）實例。不過，如果假定有一個特定編譯器和一個特定係統，那麼可能可以這樣做，幸運的是，對於Linux 上的 GCC，恰好是這種情況。 使用 ExceptionHandler 類別可以展示這一點，該類別也採用了 singleton 設計模式。其構造函數註冊了一個未捕捉的處理程序。因為每次只能有一個未捕捉的處理程序處理一個活動進程，構造函數應該只會被呼叫一次，因此要採用 singleton 模式。應該在定義有問題的實際全域（靜態全域）變數之前定義 ExceptionHandler 的全域（靜態全域）實例。 清單 3. 處理構造函數中的異常 class ExceptionHandler


{

private:

class SingleTonHandler

{

public:

SingleTonHandler()

{

set_terminate(Handler);

} static void Handler()

{

//全域變數建構/銷毀異常try

{

//重新拋出throw;

}

catch (Seg
}

catch (FloatingPointException &)

{

cout

cout

cout



cout
} //如果這是執行某些核心活動的執行緒

abort();

//否則如果這是一個用於服務請求的執行緒

// pthread_exit();

}
// pthread_exit();

}
//pthread_exit();

}

} ; public:

ExceptionHandler()

{

static STondler s_objdler s
/
{
/
static STondler s_obj; ////////////////////////////////////////////////// ///////////////////////////// ////////////////////// /// A類

{

public:

A()

{

//int i = 0, j = 1/i;

*(int *)0 = 0;0;
}; // 在定義任何全域變數之前，我們定義一個ExceptionHandler 物件的虛擬實例

// 以確保

// ExceptionHandler::SingleTonHandler::SingleHandler() 被Ton chhahadleraException ; ///////////////////////////////////////////////// ///////////////////////////////////////////////// //////////////// int main(int argc, char* argv[])

{

return 0;

}     處理多執行緒程式中的異常有時有些異常被捕獲，這將造成進程異常中止。不過很多時候，進程包含多個線程，其中少數線程執行核心應用程式邏輯，同時，其餘線程為外部請求提供服務。 假設服務執行緒由於程式錯誤而沒有處理某些異常，導致整個應用程式崩潰。這一點可能是不受好評的，因為它會透過向應用程式傳送不合法的請求而助長拒絕服務攻擊。為了避免這一點，未捕獲處理程序可以決定是請求異常中止調用，還是請求線程退出調用。清單3中ExceptionHandler::SingleTonHandler::Handler()函式的呼叫處展示了此處理程序。結論我簡單地討論了一些C++程式設計模式，以便更好地執行以下任務： ·在發送異常的時候追蹤異常的來源。

·將訊號從核心程式轉換成C++異常。

·捕捉構造和/或分析架構全域變數觸發期間出的異常。

·多執行緒進程中的異常處理。

以上就是C++程式的異常處理技巧的內容，更多相關文章請關注PHP中文網（www.php.cn）！