Delta V Software Forums

Hi,

I've found that with Xcode 4 / Clang / c++11 standard, exception thrown from destructors would cause program to terminate, even surrounded by an outer try/catch block.

The reason seems to be that destructor in C++11 are implicitly declared as noexcept, according to this email: http://lists.apple.com/archives/xcode-u ... 00024.html

By adding "noexcept(false)" declaration to destructors, this problem can be solved.

Would you please fix it in later release? Thanks.

-Su

Hi Su,

Thanks for bringing this to light. I wasn't aware of this behaviour in C++11.

Is there a particular destructor that is causing you problems?

Hi Jarl,

Yes, I've seen one.

When sending request to UDP multicast address, using RCF::Twoway option, client side will encounter a "Remote call timeout exceeded. No response from peer." exception. This exception will be caught by FutureImpl::callSync()'s try/catch block and re-throw out through FutureImpl's destructor. Normally the re-thrown exception would be caught by user's try/catch block and get processed. However since it is thrown through FutureImpl's destructor, and in C++11 destructors are declared noexcept by default, the program would abort immediately and output error message like "Terminating app due to uncaught exception."

In the above scenario, maybe RCF::Oneway should be used since there won't by any response. But I'm thinking what if a real timeout happened? The exception thrown out path might be the same.

Hope this helps.

Regards,
-Su

OK, that makes sense.

FutureImpl is a utility class that only ever exists as a temporary. I don't think there is any circumstance where it's destructor could be executed in response to another exception. The destructor has already started executing when the remote call is initiated, so any exception that happens will just pass through.

I'll mark the destructor as noexcept(false) , to suit newer compilers.

Thanks for figuring this out.