一個有效的例外情況造成分解器

我正在研究一個簡單的類來管理HKEY的生命週期。一個有效的例外情況造成分解器

class Key 
{ 
    HKEY hWin32; 
public: 
    Key(HKEY root, const std::wstring& subKey, REGSAM samDesired); 
    Key(const Key& other); 
    ~Key(); 
    Key& operator=(const Key& other); 
    Key& swap(Key& other); 
    HKEY getRawHandle() { return hWin32; }; 
}; 

//Other Methods.... 

Key::~Key() 
{ 
    LONG errorCheck 
     = RegCloseKey(hWin32); 
    /* 
    * I know it's generally bad to allow exceptions to leave destructors, 
    * but I feel that if RegCloseKey() is going to fail, the application 
    * should be terminated. (Because it should never fail.) 
    */ 
    if (errorCheck != ERROR_SUCCESS) 
     WindowsApiException::Throw(errorCheck); 
}

這是否有效的推理？我不知道RegCloseKey()的失敗怎麼傳達給被調用者。

來源

2010-02-09 Billy ONeal

作爲一名C＃程序員，這是有道理的。 – ChaosPandion 2010-02-09 01:22:51

@ChaosPandion：C＃討厭像析C++一樣從析構函數拋出異常嗎？我不確定... – 2010-02-09 01:24:31

爲什麼還要拋出異常？如果'RegCloseKey'失敗會發生什麼，你會忽略它？ – 2010-02-09 01:27:31

RegCloseKey的失敗更多的是assert的情況，而不是需要通過調用鏈傳遞的錯誤。你想坐起來注意在調試版本中，

但是有什麼好的是失敗信息去做調用者？他應該怎麼做呢？

來源

2010-02-09 01:35:24

所以你在說用'assert（errorCheck == ERROR_SUCCESS）;'行代替throw語句會更好？嗯..這似乎是一個更好的主意。 – 2010-02-09 01:38:34

@比利：是的，這就是我要說的。 – 2010-02-09 01:40:44

這不是一般不好。它是不好！

如果拋出異常，堆棧將展開直到滿足catch子句。如果其中一個Key對象位於堆棧上，則會調用析構函數。如果它拋出，你同時有兩個例外。在這種情況下，調用terminate（），所以你不會有機會對任何一個例外做任何事情。

來源

2010-02-09 01:27:03

是的，我很清楚爲什麼允許異常離開析構函數是不好的。然而，我所要求的原因是專門針對RegCloseKey - 這是除非應用程序中存在錯誤（即您傳入的錯誤類型的句柄），否則應該「永不失敗」的函數之一，並且您應該能夠在開發過程中捕捉這些錯誤。 – 2010-02-09 01:30:07

我不確定異常真的是一個調試工具。我會在這種情況下或其他機制中使用斷言，但不是我*可能能夠捕獲的異常。 – 2010-02-09 01:38:52

想想這樣 - 忽略錯誤信息的原因很糟糕，因爲如果某件事確實失敗了，那麼應該處理它並對它做某些事情（例如警告用戶，重試，等等）。然而在這種情況下，你並沒有真正處理它 - 你只是終止應用程序（這也是不好的做法）。

我建議絕對有一個斷言，以確保你在調試版本中捕獲任何東西將是很好的。使用OutputDebugString寫出一些東西可能是發佈版本的好主意。這樣，當發生錯誤時，您不會忽略應用程序，但您注意到它卻沒有終止應用程序...

終止應用程序時沒有任何警告或解釋只是混淆和刺激您的用戶....你如何向用戶解釋 - 「那麼，我無法解釋的東西以一種永遠不會發生的方式失敗，我不能忽視它，所以我必須立即退出應用程序！」？

我想我的觀點是，泄漏的手柄雖然不好，但比意外關閉應用程序要差得多。

來源

2010-02-09 01:46:04 macbutch

在釋放模式下發送調試字符串的應用程序讓我感到無法結束。賽門鐵克Ghost Systray圖標，我在看你。 – bk1e 2010-02-09 16:16:18

是的，這實際上是一個好點。爲了保護我的建議，它不會經常發生，但要公平，它並不是那麼有用（你多久看一次調試日誌纔會發現真正不太可能發生的事情）;如果應用程序有一個更合適的日誌文件... – macbutch 2010-02-16 04:33:11

一個有效的例外情況造成分解器

回答

相關問題