Re: Is there a good use case for noexcept?
On 2011-04-16 15:45, Seungbeom Kim wrote:
On 2011-04-14 17:34, DeMarcus wrote:
[...] I just want to do one remark; it's important to think of the
/semantics/ of a function. Just because a function never can throw
doesn't automatically make it noexcept.
One has to decide, from the overall design, if this shall be a
no-throw function. Maybe it isn't today, but it may be tomorrow.
One good example is all functions returning -1 when failing.
Maybe one wants to change these in the future to throw instead.
It's important to be totally clear with whether the /semantics/,
not the implementation, may throw.
If a function is changed to throw an exception instead of return -1
in case of an error, that is not just an implementation change, but
an interface change, or a change in the contract, which also justifies
a change in the function signature.
Well, yes, I think we have the same intention of achieving robust design, but to me it's important to differentiate between the /syntax/ contract and the /semantics/ contract.
If we have a function returning -1 on failure and we change it to throw an exception instead we have changed the /syntax/ contract but the /semantics/ contract stays the same, that is; this function may fail.
My idea is that noexcept shall help us keep the semantics contract intact.
Stroustrup gave the following example in N3202.
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3202.pdf
void f(int i)
{
// int a[sz]; // before
vector<int> a(sz); // after
a[i] = 7;
// ...
}
He says "We cannot build systems where an apparently small change in a function forces recompilations of all users".
I think it's unfortunate that he misses the fact that the recompilation is there to help us find flaws in the design.
Nevertheless, his example is important, so how would I solve it?
First I ask myself; what semantics contract have I promised the user of this function f()?
* If it's a function that may fail, I don't put noexcept to it neither before when using an array nor after when using the vector, hence the all-user-recompilation won't be needed.
* If it's a function that may never fail, and we feel that we must change the implementation to use a vector then we are out of luck; we can't declare this function noexcept. We could try embrace the vector within try/catch(...){} but if the vector is important for fulfilling the semantics of the function then that's not possible. (swallowing exceptions is bad behavior, but if the expression is not part of the semantics contract, like for instance logging, then I consider it legal)
I know many may be frustrated saying that the noexcept mustn't stop us from doing enhancements in our implementations, but I see it like this.
1. First of all; we don't /have/ to use noexcept all over our code, only where we need to provide strong exception guarantee.
2. Secondly; noexcept is there to help us keep the semantics contract.
3. Third; consider the alternative (or actually the current draft):
f(int i) noexcept
{
vector<int> a(sz);
a[i] = 7;
// ...
}
What happens when vector fails to construct, or a.at( BIG_NUMBER ); throws an std::out_of_range exception? Then we have two problems. The minor one is the immediate termination. The major one is that we have found a design flaw that may already be running on many customer machines.
In summary; we can either have the compiler telling us this function doesn't fulfill its contract, or we can have our customer telling us we don't fulfill the contract.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]