== Why is this an issue?

While exceptions are a common feature of modern languages, there are several reasons to potentially avoid them:

* They make the control flow of a program more difficult to understand because they introduce additional hidden exit points.
* It is difficult to introduce them gradually in a codebase that was not designed with exceptions in mind.
* They add to the size of each binary produced, thereby increasing both compile time and final executable size.
* They may incur a small performance penalty.
* The time required to handle an exception is not easy to assess, which makes them difficult to use for hard real-time applications. 

If a project decides not to use exceptions, some other error-handling mechanisms must be used. One option is to immediately terminate the process when unrecoverable errors are detected. Another one is to use the return value of the functions to convey error information and explicitly check for this value at the call sites. This error information then has to be manually propagated up the call stack until reaching a point where recovery is possible.

Starting with {cpp}23, the standard library provides the `std::expected` class that allows packing into a single object either the normal return value of a function when the execution succeeded or some error information when it failed. This type also simplifies checking for errors at the call site.

This rule raises an issue when: 

* an exception is thrown
* a ``++try++``-``++catch++`` block is used
* an exception specification (``++throw(xxx)++``) is present.

The rule applies both for {cpp} and Objective-C exception mechanisms.

=== Noncompliant code example

[source,cpp]
----
enum class MyFunctionErrors{NotALetter, NotUppercase};
double myfunction(char param) throw(MyFunctionErrors); // Noncompliant

void f() {
  try // Noncompliant
  {
    doSomething();
    throw std::runtime_error{"some error"}; // Noncompliant
  }
  catch (...)
  {
    // handle exception
  }
}
----


=== Compliant solution

[source,cpp]
----
enum class MyFunctionErrors{NotALetter, NotUppercase};
std::expected<double, MyFunctionErrors> myfunction(char param); // Compliant
void functionThatShallNotFail() noexcept; // Compliant

bool f() {
  if (!doSomething()); {
    // Handle the situation
    return false;
  }
  // Rest of the code
  return true;
}
----


=== Exceptions

``++noexcept++`` specifications are ignored because even if you choose not to use exceptions in your code, it's important to decorate as ``++noexcept++`` certain functions (for instance, move constructors that do not ``++throw++``, see S5018). This decoration can be detected by type traits, and some meta-programming techniques rely on this information.


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Remove this exception


'''
== Comments And Links
(visible only on this page)

=== on 6 Nov 2018, 20:06:46 Ann Campbell wrote:
\[~loic.joly] this phrase is odd to me "hard real-time applications" . I doubt "hard" is what you mean here (unless it's an industry term I'm unaware of?).


Also, this seems to come out of nowhere:


____
Even if you choose not to use exceptions in your code, it's important to decorate as noexcept some functions (for instance, move constructors that do not throw), because this decoration can be detected by type traits, and some meta-programming techniques rely on this information.
____


Does this mean you'll raise an issue if I don't use ``++noexcept++``?. Also, _which_ functions other than move constructors?

=== on 7 Nov 2018, 09:10:20 Loïc Joly wrote:
\[~ann.campbell.2] Hard real-time is a term I've heard in many places, and I've just checked \https://en.wikipedia.org/wiki/Real-time_computing where it is present.


No, we're not going to check anything related to noexcept (in this rule).  No longer. Current implementation flags ``++noexcept++`` as a violation, which is wrong: even if ``++noexcept++`` is something related to exceptions, it is valid to use it in a context where exception are forbidden.


I updated this RSPEC in preparation for the correction of the related false positive reported in SUPPORT-10182.


I changed the formulation, trying to make it clearer. Tell me what you think?



=== on 7 Nov 2018, 20:18:45 Ann Campbell wrote:
It's clearer [~loic.joly]. Also, it's not immediately clear to me why catching the exceptions from the code someone else wrote that I'm forced to use would raise an issue. A little expansion on that topic might be helpful.

=== on 8 Nov 2018, 09:48:24 Loïc Joly wrote:
From what I've seen from people who want to avoid exceptions, it's not that they want to avoid them in their code, they want to avoid them in the whole program (even disabling exception support in the compiler). If they use external code that might throw:

* Either they make sure to use it only in way that won't trigger an exception (just a subset of the API, or manually checking some stuff _before_ calling throwing functions)
* Or they just don't use it

I'm not sure how to explain that however. I'm not even sure it needs explaining for the users who decided to opt-in this rule;)

endif::env-github,rspecator-view[]
