Re: How on earth did noexcept get through the standards process?
On 2011-04-17 09:47, Alexander Terekhov wrote:
DeMarcus wrote:
[...]
a function that must never fail. Take for instance a function that
returns -1 on failure. It may not throw, but it's not a noexcept
function.
A function that is not supposed to throw is a noexcept function.
It depends what you mean with 'supposed'. If you in your semantics contract want to promise the users of the function that it never fails you should declare it noexcept. Just declaring a function noexcept because it doesn't throw won't help anyone, especially if you later on decides that the function should be able to fail.
For example, free() is a noexcept function, and apart from thread
cancellation, in a single thread program without
pthread_cancel(pthread_self()) (i.e. compilation without -pthread or
some such), fclose() is also a noexcept function. Note that fclose() may
fail.
This one with fclose() is tricker. Especially since many use it with RAII in the destructor. But if you think of it, if it could cause inconsistency to the system if a file failed to close (e.g. when you're saving important data) then you would probably be careful promising the users of the RAII object that it will never fail or cause inconsistency.
If you ask me, I would never let fclose() be noexcept. Instead I would force the users to embrace it with try/catch(...) just to clarify that fclose() is an old function using the return value for failure.
MyRAIIClass::~MyRAIIClass() noexcept
{
try
{
int result = fclose( handle_ );
assert( result == 0 &&
"Call the customer and blame the "
"operating system. ;)" );
}
catch(...)
{
assert( false && "Why is it throwing?" );
}
}
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]