一个有效的例外情况造成分解器

我正在研究一个简单的类来管理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

一个有效的例外情况造成分解器

回答

相关问题