内容简介:January 16th, 2020A customer had a plug-in model where the plug-in could respond to a request in three ways.The customer acknowledges that this design
Raymond
January 16th, 2020
A customer had a plug-in model where the plug-in could respond to a request in three ways.
HRESULT
The customer acknowledges that this design has made a lot of people very angry and been widely regarded as a bad move .¹ But they don’t have a time machine, so they have to live with their mistakes.
The customer wanted to know whether it was appropriate to use _set_se_translator
to convert the Win32 structured exception to a C++ exception:
class win32_exception { /* ... */ }; void translate_to_custom_exception(unsigned int code, PEXCEPTION_POINTERS pointers) { throw win32_exception(code, get_stack_trace(pointers)); } void InvokeCallback(CALLBACK_FUNCTION fn, /* other arguments */) { auto previousTranslator = _set_se_translator(translate_to_custom_exception); try { HRESULT hr = fn(/* other arguments */); /* ... handle various return codes ... */ } catch (const win32_exception& ewin32) { /* ... handle structured exception ... */ } catch (const std::bad_alloc&) { /* ... handle low memory ... */ } catch (const foo_exception& efoo) { /* ... handle foo exception ... */ } /* and so on */ _set_se_translator(previousTranslator); }
The customer wanted to know whether it was okay to mix C++ and structured exceptions in this way.
Yes,it’s legal. to mix C++ exceptions and structured exceptions this way. In fact, it’s the stated purpose of the _set_se_translator
function. It lets you replace the default “convert a structured exception into a C++ exception” translator with a custom one.
It may appear at first glance that you are applying a global solution to a local problem, because the _set_se_translator
looks like it is going to change the translator for the entire process, which can result in confusing multithreading problems. But no fear, the structured exception translator is maintained on a per-thread basis. (Assuming you’re using the multithreading version of the runtime library, which you’d better be using if you’re multithreaded.)
However, there is still a little bit of the global/local problem, because the custom translator is in effect during the error handling phase of the function, after the plug-in has returned. The custom translator should be scoped tightly around the call to the plug-in. That way, you don’t accidentally activate it if a structured exception is raised in one of the catch
clauses, or any of the other code that isn’t the call to the plug-in.
Furthermore, there’s a problem if the plug-in throws an exception that wasn’t explicitly caught. In that case, this code never restores the original translator. We can solve this problem by using an RAII type, so that the exception unwinder will restore the translator.
struct translator_guard { translator_guard(_se_translator_function translator) : previous_translator(_set_se_translator(translator)) { } ~translator_guard() { _set_se_translator(previous_translator); } // Rule of three translator_guard(const translator_guard&) = delete; translator_guard& operator=(const translator_guard&) = delete; private: _se_translator_function previous_translator; }; void InvokeCallback(CALLBACK_FUNCTION fn, /* other arguments */) { try { HRESULT hr; { translator_guard guard(translate_to_custom_exception); hr = fn(/* other arguments */); } /* ... handle various return codes ... */ } catch (const win32_exception& ewin32) { /* ... handle structured exception ... */ } catch (const std::bad_alloc&) { /* ... handle low memory ... */ } catch (const foo_exception& efoo) { /* ... handle foo exception ... */ } /* and so on */ }
Using an RAII type ensures that the translator is reset even if an exception is raised.
To avoid the bare nested scope, we could factor the the scary bits into a separate function.
HRESULT InvokeWithCustomExceptionTranslation( CALLBACK_FUNCTION fn, /* other arguments */) { translator_guard guard(translate_to_custom_exception); return fn(/* other arguments */); } void InvokeCallback(CALLBACK_FUNCTION fn, /* other arguments */) { try { HRESULT hr = InvokeWithCustomExceptionTranslation( fn, /* other arguments */); /* ... handle various return codes ... */ } catch (const win32_exception& ewin32) { /* ... handle structured exception ... */ } catch (const std::bad_alloc&) { /* ... handle low memory ... */ } catch (const foo_exception& efoo) { /* ... handle foo exception ... */ } /* and so on */ }
The customer further noted that _set_se_translator
requires /EHa
, and they dutifully compiled their entire program with /EHa
, but they were wondering if that was actually necessary. Is there an alternate design that avoids the need for /EHa
? (Related.)
We’ll take up the follow-up question next time.
Bonus chatter : I could have written
template<typename TLambda> auto WithCustomExceptionTranslation( TLambda&& lambda) { translator_guard guard(translate_to_custom_exception); return lambda(); }
and call it from InvokeCallback
like this:
HRESULT hr = WithCustomExceptionTranslation( [&] { return fn(/* other arguments */); });
Is this a good thing or a bad thing?
¹ I suspect that this was not the original design for the plug-in model, but people abused the plug-in model so much that they ended up forced to support it, for compatibility reasons.
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
C程序设计语言
Brian W. Kernighan、Dennis M. Ritchie / 机械工业出版社 / 2006-8-1 / 35.00元
在计算机发展的历史上,没有哪一种程序设计语言像C语言这样应用广泛。本书是C语言的设计者之一Dennis M.Ritchie和著名计算机科学家Brian W.Kernighan合著的一本介绍C语言的权威经典著作。我们现在见到的大量论述C语言程序设计的教材和专著均以此书为蓝本。本书第1版中介绍的C语言成为后来广泛使用的C语言版本——标准C的基础。人们熟知的“hello,World"程序就是由本书首次引......一起来看看 《C程序设计语言》 这本书的介绍吧!