情景:
我们有一个具有通用错误处理接口的API。它是一个C API,因此它告诉我们在调用每个API函数之后,我们需要执行一些这样的样板:
if (APIerrorHappened()) {
APIHandle h;
while(h = APIgetNextErrorContext(...)) {
cerr << APIgetText(h) << endl;
}
}
你显然讨厌重复自己,所以你想把这个处理封装在一个允许你编写这样代码的宏中:
...
// this API call returns something
APItype foo = MYMACRO(APIsomeFunction1(...));
// this one doesn't
MYMACRO(APIsomeFunction2(...));
// neither does this (glCompileShader)
MYMACRO(APIsomeFunction3(...));
...
你也可以从面向方面的编程来考虑这一点 - 想象一下宏添加日志记录,将信息发送到远程监视器,无论如何......重点是它应该封装表达式,做任何事情围绕它,并返回表达式返回的任何类型 - 当然表达式可能不会返回任何。
这意味着你不能只做
#define MYMACRO(x) { auto x = expr(); ... }
...因为在某些情况下,表达式不会返回任何内容!
那么......你会怎么做?
请不要建议在宏中封装完整的语句...
#define MYMACRO(x) \
{ \
/* ... stuff ... */ \
x; \
// ... stuff
}
...因为这对以下内容无效:
if (foo() || APIfunctionReturningBool(...) || bar()) {
...
APIfunction1();
...
} else if (APIOtherfunctionReturningBool() || baz()) {
...
APIfunction2();
...
}
...你吞没了所有if语句?它的动作包括其他API调用,所以...宏内的宏?调试变得很糟糕。
我自己的尝试在下面,使用lambdas和std :: function - 但它可以说是丑陋的...... 我无法将表达式的lambda直接传递给采用std :: function的模板(基于lambda的返回类型进行专门化),因此代码变得非常讨厌。
你能想到一个更好的方法吗?
void commonCode(const char *file, size_t lineno) {
// ... error handling boilerplate
// ... that reports file and lineno of error
}
template <class T>
auto MyAPIError(std::function<T()>&& t, const char *file, size_t lineno) -> decltype(t()) {
auto ret = t();
commonCode(file,lineno);
return ret;
}
template<>
void MyAPIError(std::function<void(void)>&& t, const char *file, size_t lineno) {
t();
commonCode(file,lineno);
}
template <class T>
auto helper (T&& t) -> std::function<decltype(t())()>
{
std::function<decltype(t())()> tmp = t;
return tmp;
}
#define APIERROR( expr ) \
return MyAPIError( helper( [&]() { return expr; } ), __FILE__, __LINE__);
更新,KennyTM优秀解决方案的附录
我放置了触发此问题的实际OpenGL代码here。正如您所看到的,错误检查代码不仅仅是打印 - 它还引发了用户代码可以处理的异常。我正在添加这个附录,注意到使用KennyTM的解决方案,你最终会从析构函数中抛出这个异常,并且这没关系(继续阅读):
struct ErrorChecker {
const char *file;
size_t lineno;
~ErrorChecker() {
GLenum err = glGetError();
if (err != GL_NO_ERROR) {
while (err != GL_NO_ERROR) {
std::cerr <<
"glError: " << (char *)gluErrorString(err) <<
" (" << file << ":" << lineno << ")" << std::endl;
err = glGetError();
}
throw "Failure in GLSL...";
}
}
};
在C++ FAQ中解释了从这个析构函数中抛出的原因:3>:
C ++规则是你必须永远不要从另一个异常的“堆栈展开”过程中被调用的析构函数中抛出异常......你可以说在处理另一个异常时,绝不会从析构函数中抛出异常例外即可。
在我们的例子中,我们希望用户代码(调用特殊宏)来处理异常;所以我们需要确定我们在ErrorChecker的析构函数中的“抛出”是第一个 - 即被调用的实际C API永远不会抛出。这可以通过以下形式轻松完成:
#define GLERROR(...) \
([&]() -> decltype(__VA_ARGS__) \
{ \
ErrorChecker _api_checker {__FILE__, __LINE__}; \
(void) _api_checker; \
try { \
return __VA_ARGS__; \
} catch(...) {} \
} ())
这种形式的宏保证实际的C API(通过 VA_ARGS 调用)永远不会抛出 - 因此,ErrorChecker的析构函数中的“throw”将始终是第一个< / strong>这样做。
因此,此解决方案涵盖了我原始问题的所有角度 - 非常感谢Alexander Turner提供它。
答案 0 :(得分:2)
将日志记录代码放到某个类的析构函数中 - 假设记录器不会抛出 - 然后在宏中创建该类的实例。滥用逗号运算符,我们有:
struct Logger
{
const char* file;
int lineno;
~Logger()
{
// The APIerrorHappened stuff.
}
};
#define APIERROR(...) (Logger{__FILE__, __LINE__}, (__VA_ARGS__))