I.10 exceptions clarification

[imre-palik]

As I am not a native speaker of English, the issue might have been in my side, but could somebody make the "what is an error" note a bit easier to read? After reading it a few times, I still don't understand what it is supposed to mean.

As for the section about performance not being a valid reason. I think it should be more clear here that exceptions are not supposed to be used to implement control flow.

Actually at https://softwareengineering.stackexchange.com/questions/189222/are-exceptions-as-control-flow-considered-a-serious-antipattern-if-so-why
There is a pretty clear definition by Mason Wheeler when exceptions should be used. Could we adopt something like that instead of the "what is an error" section?

The other big question that this rule is fails to answer is when to use [[nodiscard]] . As [[nodiscard]] also seems to be a good sollution for the stated reason of this rule.

[cubbimew]

The note currently says

What is an error?
An error means that the function cannot achieve its advertised purpose (including establishing postconditions)

Would "satisfy its contract" be clearer than "achieve its advertised purpose"?

[imre-palik]

After thinking a bit about this, I think I know what made me hard to understand this.

First of all, the title itself suggests that this rule is about using exceptions for general error handling. And of course the word error is also strongly overloaded, and thus increases the confusion.

Possibly changing the title to "Use exceptions to signal a critical failure to perform a required task"
and replace the word "error" to "faliure" or "serious error" would help.

[MikeGitb]

Would "satisfy its contract" be clearer than "achieve its advertised purpose"?

Contract is a heavily overloaded term depending on who you speak with, but imho signaling of errors via exceptions is part of the contract.

I think the current formulation is fine. Alternatively I've heard the phrase "can't establish its post conditions" which is more precise, but again it is unclear to me if e.g. vector::push_back really hasn't established it's post conditions if it exits via an exception, but correctly honors the strong exception guarantee.

[imre-palik]

Would it be possible to simply remove this rule? Secion E does way more justice to this topic.

[hsutter]

We aim to clarify. I wrote the original text so I'll take this one. I'll be careful to avoid wording that is confusing with C++20's new contracts feature.