
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">

<style>
pre {font-family: "Consolas", "Lucida Console", monospace; margin-left:20pt; }
code {font-family: "Consolas", "Lucida Console", monospace; }
pre > i   { font-family: "Consolas", "Lucida Console", monospace;  font-style:italic; }
code > i  { font-family: "Consolas", "Lucida Console", monospace;  font-style:italic; }
pre > em  { font-family: "Consolas", "Lucida Console", monospace;  font-style:italic; }
code > em { font-family: "Consolas", "Lucida Console", monospace;  font-style:italic; }
dl > dt { font-style:italic; }
body { font-family: "Calibri" }

@media (prefers-color-scheme: dark) {
	body { background: #111; color:  #ccc; }
	a { color:  #38f; }
	a:visited { color:  #a4d; }
	.sect { color:  #ccc; }
    del { text-decoration: line-through; color: #EE9999; }
    ins { text-decoration: underline; color: #99EE99; }
    blockquote.std    { color: #ccc; background-color: #2A2A2A;  border: 1px solid #3A3A3A;  padding-left: 0.5em; padding-right: 0.5em; }
    blockquote.stddel { text-decoration: line-through;  color: #ccc; background-color: #221820;  border: 1px solid #332228;  padding-left: 0.5em; padding-right: 0.5em; ; }
    blockquote.stdins { text-decoration: underline;  color: #ccc; background-color: #182220;  border: 1px solid #223328; padding: 0.5em; }
    table { border: 1px solid #ccc; border-spacing: 0px;  margin-left: auto; margin-right: auto; }
}

@media (prefers-color-scheme: light) {
	body { background:  white; color: black; }
    del { text-decoration: line-through; color: #8B0040; }
    ins { text-decoration: underline; color: #005100; }
    blockquote.std    { color: #000000; background-color: #F1F1F1;  border: 1px solid #D1D1D1;  padding-left: 0.5em; padding-right: 0.5em; }
    blockquote.stddel { text-decoration: line-through;  color: #000000; background-color: #FFEBFF;  border: 1px solid #ECD7EC;  padding-left: 0.5em; padding-right: 0.5em; ; }
    blockquote.stdins { text-decoration: underline;  color: #000000; background-color: #C8FFC8;  border: 1px solid #B3EBB3; padding: 0.5em; }
    table { border: 1px solid black; border-spacing: 1px;  margin-left: auto; margin-right: auto; }
}


.comment em { font-family: "Calibri"; font-style:italic; }
p.example   { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }
div.poll { margin-left: 2em; }

code.extract { background-color: #F5F6A2; }
pre.extract  { margin-left: 2em; background-color: #F5F6A2;  border: 1px solid #E1E28E; }

p.function    { }
.attribute    { margin-left: 2em; }
.attribute dt { float: left; font-style: italic;  padding-right: 1ex; }
.attribute dd { margin-left: 0em; }

.editor { color: #4444BB; font-style: normal; background-color: #DDDDDD; }

tab { padding-left: 4em; }
tab3 { padding-left: 3em; }

.link { float: right; font-family: "Consolas", "Lucida Console", monospace; font-size:80% }


table.header { border: none; border-spacing: 0;  margin-left: 0px; font-style: normal; }
td.header { border: none; border-spacing: 0;  margin-left: 0px; font-style: normal; }
.header { border: none; border-spacing: 0;  margin-left: 0px; font-style: normal; }
table.poll { border: 1px solid black; border-spacing: 0px;  margin-left: 0px; font-style: normal; }

th { text-align: left; vertical-align: top;  padding-left: 0.4em;  /*padding-right: 0.4em; border-bottom:1px dashed;*/ }
td { text-align: left;  padding-left: 0.4em; padding-right: 0.4em; /*border-right:1px dashed; */}
tr { border: solid; border-width: 1px 0; border-bottom:1px solid blue }


.revision   { /*color: #005599;*/ }
.grammar { list-style-type:none }

</style>

<title>Violation handlers vs `noexcept`</title>

</head>
<body>  

<table class="header"><tbody>
  <tr>
    <th>Document number:&nbsp;&nbsp;</th><th> </th><td class="header">P3541R1</td>
  </tr>
  <tr>
    <th>Date:&nbsp;&nbsp;</th><th> </th><td class="header">2025-01-06</td>
  </tr>
  <tr>
    <th>Audience:&nbsp;&nbsp;</th><th> </th><td class="header">SG21, SG23, EWG</td>
  </tr>
  <tr>
    <th>Reply-to:&nbsp;&nbsp;</th><th> </th><td class="header">
        <address>Andrzej Krzemieński &lt;akrzemi1 at gmail dot com&gt;</address>
    </td>
  </tr>
</tbody></table>



<h1>Violation handlers vs <code>noexcept</code></h1>


<p> In this paper we point out that a number of correctness-checking features
    currently considered for addition to C++ that allow responding 
    to run-time-detected violations via exceptions, should
    define the interaction with the <code>noexcept</code>-specifier, with the
    <code>noexcept</code>-operator, and also specify what can be expected of stack
    unwinding in the case of a detected violation.
    </p>


<h2><a class="sect" id="0">0.</a> Revision history</h2>

<h3><a class="sect" id="0.1">0.1.</a> R0 → R1</h2>

<ul>
    <li>Apart from <code>noexcept</code> we now also consider stack unwinding guarantees.</li>
    <li>Restructured the discussion to make it clear that the <code>noexcept</code>-operator
        and the <code>noexcept</code>-specifier are two separate issues.
        </li>
</ul>


<h2><a class="sect" id="1">1.</a> The context</h2>


<p> There is a number of proposals currently on the flight aiming at detecting at run-time
    the incorrect usages of the language or libraries, and responding to them in a number of ways,
    including by throwing an exception. These proposals include:</p>

<ol>
  <li><a href="https://isocpp.org/files/papers/P2900R11.pdf"
       title="Joshua Berne, Timur Doumler, Andrzej Krzemieński et al., &ldquo;Contracts for C++&rdquo;">[P2900R11]</a>
      &mdash; Contracts for C++,
      </li>
  <li><a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3471r2.html"
       title="Konstantin Varlamov, Louis Dionne, &ldquo;Standard library hardening&rdquo;">[P3471R2]</a>
      &mdash; Standard library hardening,
      </li>
  <li><a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3100r1.pdf"
       title="Timur Doumler, Gašper Ažman, Joshua Berne, &ldquo;Undefined and erroneous behaviour is a contract violation&rdquo;">[P3100R1]</a>
       &mdash; Undefined and erroneous behaviour is a contract violation,
       </li>
  <li><a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf"
       title="Herb Sutter, &ldquo;Core safety Profiles: Specification, adoptability, and impact&rdquo;">[P3081R0]</a>
      &mdash; Core safety profiles.
      </li>    
</ol>


<p> <a href="https://isocpp.org/files/papers/P2900R11.pdf"
       title="Joshua Berne, Timur Doumler, Andrzej Krzemieński et al., &ldquo;Contracts for C++&rdquo;">[P2900R11]</a>
    introduces the notion of a <em>violation handler:</em>
    a user-customisable function that is invoked in response to a violation of a user-planted
    <em>contract assertion</em> detected at run-time.
    One of the intended use cases for this handler is for the programmer
    to be able to throw an exception that would on the one hand prevent the execution of the 
    following expression, and on the other resume the program execution from another location.
    </p>
    
<p> <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3471r2.html"
       title="Konstantin Varlamov, Louis Dionne, &ldquo;Standard library hardening&rdquo;">[P3471R2]</a>
    wants to employ the same violation handler mechanism for reporting the violations of 
    preconditions of certain Standard Library functions (not necessarily expressed with contract assertions).
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3100r1.pdf"
       title="Timur Doumler, Gašper Ažman, Joshua Berne, &ldquo;Undefined and erroneous behaviour is a contract violation&rdquo;">[P3100R1]</a>
    proposes (among other things) to put an <em>implicit</em> contract assertion 
    (which may end up calling a violation handler) in front of
    every expression with a potential to trigger an <em>easily detectable undefined behavior,</em> such as null
    pointer dereference or integer division by zero. Finally,
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf"
       title="Herb Sutter, &ldquo;Core safety Profiles: Specification, adoptability, and impact&rdquo;">[P3081R0]</a>
    proposes that under certain predefined profiles, a subset of expressions with easily detectable UB
    situations from <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3100r1.pdf"
       title="Timur Doumler, Gašper Ažman, Joshua Berne, &ldquo;Undefined and erroneous behaviour is a contract violation&rdquo;">[P3100R1]</a>
    &mdash; namely, null pointer dereference, element access operator call and integer overflow &mdash; 
    be preceded by an implicit contract assertion.    
    </p>
    
<p> In case 
    <a href="https://isocpp.org/files/papers/P2900R11.pdf"
       title="Joshua Berne, Timur Doumler, Andrzej Krzemieński et al., &ldquo;Contracts for C++&rdquo;">[P2900R11]</a>
    isn't accepted for C++26,
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3471r2.html"
       title="Konstantin Varlamov, Louis Dionne, &ldquo;Standard library hardening&rdquo;">[P3471R2]</a>&rsquo;s
    plan B is to just terminate (in an unspecified way) and there will be no question of throwing.
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf"
       title="Herb Sutter, &ldquo;Core safety Profiles: Specification, adoptability, and impact&rdquo;">[P3081R0]</a>&rsquo;s
    plan B is to devise its own mechanism of a contract violation handler, with the same 
    set of questions to be addressed.
        </p>



<h2><a class="sect" id="2">2.</a> The use case</h2>


<p> There are two use cases for throwing violation handlers.</p>

<ol>
<li>To unit-tests the presence of run-time correctness checks in the body of a function.</li>
<li>To restore a program that was about to execute an operation out of contract,
    to a state where it can correctly continue the execution.</li>
</ol>

<p> The first case has been described in detail in 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf"
        title="Alisdair Meredith, John Lakos, &ldquo;noexcept Prevents Library Validation&rdquo;">[N3248]</a>,
    is well understood, and only applies to unit tests, so programs that can afford some
    glitches like memory leaks. In this paper we will be focusing on the second case.</p>
    
    
<p> We will call this use case <em>recover-from-a-bug</em>.</p>

<p> In order to explain it we will introduce another term:
    <em>imminent undefined behavior.</em> Under some proposed features an implementation 
    may insert a run-time check before a given expression <code>E</code> that determines,
    by evaluating a boolean predicate, if the evaluation of <code>E</code> would result
    in undefined behavior. If this run-time check detects that the undefined behavior
    would take place, we call this run-time situation an imminent undefined behavior,
    but it is not undefined behavior just yet. For example, under proposal 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3100r1.pdf"
       title="Timur Doumler, Gašper Ažman, Joshua Berne, &ldquo;Undefined and erroneous behaviour is a contract violation&rdquo;">[P3100R1]</a>
    an implementation inserts before an expression <code>*p</code> a run-time check if 
    <code>p</code> is null. If this run-time check at some point discovers that <code>p</code>
    is indeed null, this is imminent undefined behavior. But expression <code>*p</code>
    has not yet executed, and may never will because the implementation can also insert an
    instruction (such as program termination) that will cause the evaluation of the expression
    never to be reached.
    </p>
    
<p> Now, the use case: Upon an imminent undefined behavior or a contract violation we want the 
    control to be transferred to the higher layers of the program which can decide how to
    clean up the critical resources and reset the state of the program. We cannot afford
    to terminate the program and rely on an external process to re-run it,
    because our program is the only process that is running on the hardware.    
    </p>
    
<p> Because the detection of the imminent undefined behavior or contract violation 
    is an indication of a software bug that has 
    happened <em>earlier</em> in the program execution, there is a chance that the bug 
    originates in the higher layers of the program, and such a restart will not work.
    So the engineers take a <em>chance</em>.
    </p>


<!-- semantics controlled by a profile
implicit contracts only ignore or quick_enforce -->


<h2><a class="sect" id="3">3.</a> The problems</h2>

<h3><a class="sect" id="3.1">3.1.</a> Stack unwinding for unannounced throw</h3>

<p> In this paper we use term <em>unannounced throw</em> to refer to a throw from a 
    violation handler.</p>

<p> Given the following code</p>

<pre>
void set_positive(int* pValue)
{
  std::lock_guard _ {_mutex}; 
  _result = (*pValue &gt; 0);  <em>// i</em>
}</pre>

<p> if the pointer dereference ends in a throw, as per 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf"
       title="Herb Sutter, &ldquo;Core safety Profiles: Specification, adoptability, and impact&rdquo;">[P3081R0]</a>,
    is it guaranteed that <code>_mutex</code>
    is unlocked? Today, in C++23, the expression statement denoted with <code><em>i</em></code>
    cannot throw, so the implementation can just emit a call to <code>unlock</code> as
    a regular instruction, without caring if the instruction is also invoked upon stack unwinding.
    </p> 

<p> In the 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf"
       title="Herb Sutter, &ldquo;Core safety Profiles: Specification, adoptability, and impact&rdquo;">[P3081R0]</a>
    world, either the destructor call is guaranteed upon unannounced throw, and there is
    a run-time penalty to be paid even in the correct code (either as a longer execution time
    or as a bigger executable), or we have a different kind of stack unwinding that
    doesn't guarantee that destructors are called. Or maybe, rather than having the implementation 
    choose between just two &mdash; calling the violation handler and not calling the handler &mdash;
    we should have it choose between three: not calling it, calling it with normal stack unwinding upon throw,
    and calling it with the degenerate stack unwinding upon throw?
    </p>  

<p> In a similar vein, a code that guarantees <em>strong</em> (transactional) exception safety 
    (<a href="https://www.boost.org/community/exception_safety.html"
        title="David Abrahams, &ldquo;Exception-Safety in Generic Components&rdquo;">[ABRAHAMS]</a>),
    which relies on some operations never throwing, may no longer work for these new
    unannounced throws.
    </p>
    
<p> An argument is often brought up that these new unannounced throws would only show up
    in places where we had undefined behavior before, so the unannounced throw is no worse
    than the previous UB. However, such attitude is not enough to satisfy the use case 
    <em>recover-from-a-bug</em>. After all, we are talking about a change from something 
    that used to be undefined behavior into something that has a well defined behavior.
    Proposals like 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf"
       title="Herb Sutter, &ldquo;Core safety Profiles: Specification, adoptability, and impact&rdquo;">[P3081R0]</a>
    or
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3100r1.pdf"
       title="Timur Doumler, Gašper Ažman, Joshua Berne, &ldquo;Undefined and erroneous behaviour is a contract violation&rdquo;">[P3100R1]</a>
    should make it clear if they want to support the use case, and if they do, specify clearly
    how the program behaves in the face of such unannounced throws.
    </p>  


<h3><a class="sect" id="3.2">3.2.</a> Hitting the <code>noexcept</code> barrier</h3>


<p> The unannounced throw which can now happen nearly anywhere can cause an exception
    to escape from a <code>noexcept</code> function. Note that destructors are 
    implicitly annotated as <code>noexcept</code>. Consider:
    </p>
    
<pre>Tool::~Tool() <em>// noexcept by default</em>
{ 
  for (int i = 0; i &lt;= size(); ++i) {
    _vector[i].retire(i);
  }
}
</pre>

<p> If the out-of-bounds access is detected and turned into a throw, this will cause 
    <code>std::terminate()</code> to be called, and will compromise the  
    <em>recover-from-a-bug</em> use case.
    </p>
    
<p> Solutions proposed in 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2784r0.html"
       title="Andrzej Krzemieński, &ldquo;Not halting the program after detected contract violation&rdquo;">[P2784R0]</a>
    and 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3205r0.pdf"
       title="Gašper Ažman, Jeff Snyder, Andrei Zissu, Ben Craig, &ldquo;Throwing from a noexcept function should be a contract violation.&rdquo;">[P3205R0]</a>
    offer a way to perform sort-of-a-stack-unwinding that can propagate across 
    <code>noexcept</code> barriers while skipping the destructor calls.
    </p>



<h3><a class="sect" id="3.3">3.3.</a> The <code>noexcept</code> operator</h3>


<p> In C++23 the value of expression</p>

<pre>noexcept(p->clear())</pre>

<p> is <code>true</code>. What should be its value under 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf"
       title="Herb Sutter, &ldquo;Core safety Profiles: Specification, adoptability, and impact&rdquo;">[P3081R0]</a>
    or
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3100r1.pdf"
       title="Timur Doumler, Gašper Ažman, Joshua Berne, &ldquo;Undefined and erroneous behaviour is a contract violation&rdquo;">[P3100R1]</a>,
    given that the null pointer dereference can call a violation handler that throws?
    </p>


<p> The possible answers to this question, partially overlapping with these from
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2969r0.pdf"
       title="Timur Doumler, Ville Voutilainen, Tom Honermann, &ldquo;Contract annotations are potentially-throwing&rdquo;">[P2969R0]</a>,
    are:</p>

<ol> 
    <li>Any construct that might end up in either undefined behavior or contract violation 
        is potentially-throwing and this is reflected by the <code>noexcept</code>-operator.
        This goes against the direction in 
        <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf"
           title="Herb Sutter, &ldquo;Zero-overhead deterministic exceptions: Throwing values&rdquo;">[P0709R4]</a>
        or in 
        <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3166r0.html"
           title="Lewis Baker, &ldquo;Static Exception Specifications&rdquo;">[P3166R0]</a>.        
    </li>
    <li>All these constructs are non-throwing, reflected by the <code>noexcept</code>-operator, 
        and we accept that throwing from a violation handler is disallowed.
    </li>
    <li>The said constructs are either observably non-throwing or observably 
        potentially-throwing based on some configuration, maybe a compiler switch. 
        The result is
        that a correct program can take different paths based on configuration.
        </li>
    <li>The said contracts are <code>noexcept(true)</code> but can throw nonetheless in 
        case the violation handler throws. This would set the meaning of <code>noexcept</code>
        to "expression does not throw as long as it does not violate any contract".
        </li>
    <li>Keep avoiding the answer for <a href="https://isocpp.org/files/papers/P2900R11.pdf"
          title="Joshua Berne, Timur Doumler, Andrzej Krzemieński et al., &ldquo;Contracts for C++&rdquo;">[P2900R11]</a>.
        For the imminent undefined behavior cases allow only semantics <em>ignore</em> 
        and <em>quick_enforce</em>, which have no means of causing an exception to be
        thrown. This can be later expanded to semantics like <em>observe</em> and <em>enforce</em>
        but which turn a throw into a program termination.</li>
</ol>

    
    
    
<h2><a class="sect" id="4">4.</a> The interaction with contracts</h2>


<p> Contracts (<a href="https://isocpp.org/files/papers/P2900R11.pdf"
       title="Joshua Berne, Timur Doumler, Andrzej Krzemieński et al., &ldquo;Contracts for C++&rdquo;">[P2900R11]</a>)
    are special in this regard, as the run-time checks are never added implicitly
    but require an explicit usage of either <code>pre</code> or 
    <code>post</code> on function declarations or <code>contract_assert</code> as a
    statement.
    </p>
    
<p> <a href="https://isocpp.org/files/papers/P2900R11.pdf"
       title="Joshua Berne, Timur Doumler, Andrzej Krzemieński et al., &ldquo;Contracts for C++&rdquo;">[P2900R11]</a>
       
    clearly defines the interaction with <code>noexcept</code>. 
    Preconditions and postconditions, even if physically checked in the caller, 
    interact with <code>noexcept</code> as if they were evaluated inside the function body.     
    <code>contract_assert</code> is a statement rather than an expression, so that its
    non-throwing property cannot be tested in any way. 
    </p>

<p> However, while this works for now, we know of two features that propose to be able
    to test the non-throwing property of arbitrary statements:</p>
    
<ol>
    <li><a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3166r0.html"
       title="Lewis Baker, &ldquo;Static Exception Specifications&rdquo;">[P3166R0]</a>
       &mdash; <em>Static Exception Specifications,</em> where you can annotate your function
       with <code>throw(auto)</code> which will deduce the exception specification from all 
       statements in the function body,
       </li>
    <li><a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2806r2.html"
       title="Bruno Cardoso Lopes, Zach Laine, Michael Park, Barry Revzin, &ldquo;do expressions&rdquo;">[P2806R2]</a>
     &mdash; <em><code>do</code> expressions,</em> which turn a sequence of statements into an 
      expression which you can inspect with the <code>noexcept</code>-operator.
      </li>
</ol>

<p> If either of these features is added, the question will need to be answered:
    is <code>contract_assert</code> potentially-throwing? 
    </p>
    
<p> The evaluation of 
    <code>contract_assert</code> could throw for two reasons: either because the violation
    handler throws, or because the tested predicate throws. If the direction should be that
    assertion statements are non-throwing, we could end up with an interesting result that
    </p>
 
 <pre>noexcept(contract_assert((throw 1, false)))</pre>
 
 <p>returns <code>true</code>.</p>



<h2><a class="sect" id="5">5.</a> Conclusion</h2>



<p> Given that the same idea — potentially throwing in a controlled way from every place 
    that is either an imminent undefined behavior or a contract violation — surfaces in a number of proposals, the C++ community
    would benefit from a clear design direction in this respect.
    </p>
    
<p> Any proposal in this space should clearly state if use case <em>recover-from-a-bug</em>
    is supported, and how: what is guaranteed and what is not.
    </p>
       
  
<h2><a class="sect" id="6">6.</a> Acknowledgments</h2>  

<p> A number of observations in this paper comes from SG21 reflector participants, 
    in particular Ville Voutilainen and Anthony Williams. Timur Doumler and Herb Sutter
    suggested improvements and corrections to the paper. The list of suggested 
    solutions comes from 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2969r0.pdf"
       title="Timur Doumler, Ville Voutilainen, Tom Honermann, &ldquo;Contract annotations are potentially-throwing&rdquo;">[P2969R0]</a>.
    </p>
       
       
<h2><a class="sect" id="7">7.</a> References</h2>


<ul>



    <li>
        [ABRAHAMS] — David Abrahams,
        "Exception-Safety in Generic Components"<br>
        (<a href="https://www.boost.org/community/exception_safety.html">https://www.boost.org/community/exception_safety.html</a>).
    </li>
    <!--
    <a href="https://www.boost.org/community/exception_safety.html"
        title="David Abrahams, &ldquo;Exception-Safety in Generic Components&rdquo;">[ABRAHAMS]</a>
    -->

    <li>
        [N2855] — Douglas Gregor, David Abrahams,
        "Rvalue References and Exception Safety"<br>
        (<a href="https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html">https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html</a>).
    </li>
    <!--
    <a href="https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html"
        title="Douglas Gregor, David Abrahams, &ldquo;Rvalue References and Exception Safety&rdquo;">[N2855]</a>
    -->

    <li>
        [N2983] — David Abrahams, Rani Sharoni, Doug Gregor,
        "Allowing Move Constructors to Throw"<br>
        (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2983.html"
            >https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2983.html</a>).
    </li>
    <!--
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2983.html"
        title="David Abrahams, Rani Sharoni, Doug Gregor, &ldquo;Allowing Move Constructors to Throw&rdquo;">[N2983]</a>
    -->
    
        <li>
        [N3248] — Alisdair Meredith, John Lakos,
        "noexcept Prevents Library Validation"<br>
        (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf</a>).
    </li>
    <!--
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf"
        title="Alisdair Meredith, John Lakos, &ldquo;noexcept Prevents Library Validation&rdquo;">[N3248]</a>
    -->
    
    
<li>[P0709R4] — Herb Sutter, "Zero-overhead deterministic exceptions: Throwing values" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf"
       title="Herb Sutter, &ldquo;Zero-overhead deterministic exceptions: Throwing values&rdquo;">[P0709R4]</a>
    -->
    
    
    
    <li>
        [P2698R0] — Bjarne Stroustrup, "Unconditional termination is a serious problem" <br>
        (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2698r0.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2698r0.pdf</a>).
    </li>
    <!--
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2698r0.pdf"
       title="Bjarne Stroustrup, &ldquo;Unconditional termination is a serious problem&rdquo;">[P2698R0]</a>
    -->
    
     <li>
        [P2780R0] — Ville Voutilainen,
        "Caller-side precondition checking, and Eval_and_throw"<br>
        (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2780r0.html">
            https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2780r0.html
        </a>).
    </li>
    <!--
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2780r0.html"
        title="Ville Voutilainen, &ldquo;Caller-side precondition checking, and Eval_and_throw&rdquo;">[P2780R0]</a>
    -->


<li>[P2784R0] — Andrzej Krzemieński, "Not halting the program after detected contract violation" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2784r0.html">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2784r0.html</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2784r0.html"
       title="Andrzej Krzemieński, &ldquo;Not halting the program after detected contract violation&rdquo;">[P2784R0]</a>
    -->

<li>[P2806R2] — Bruno Cardoso Lopes, Zach Laine, Michael Park, Barry Revzin, "<code>do</code> expressions" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2806r2.html">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2806r2.html</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2806r2.html"
       title="Bruno Cardoso Lopes, Zach Laine, Michael Park, Barry Revzin, &ldquo;do expressions&rdquo;">[P2806R2]</a>
    -->
    
    
<li>[P2858R0] — Andrzej Krzemieński,
    "Noexcept vs contract violations", <br>
    (<a href="https://isocpp.org/files/papers/P2858R0.html">"https://isocpp.org/files/papers/P2858R0.html"</a>).
    </li>
    <!--
    <a href="https://isocpp.org/files/papers/P2858R0.html"
       title="Andrzej Krzemieński, &ldquo;Noexcept vs contract violations&rdquo;">[P2858R0]</a>
    -->
          
<li>[P2900R11] — Joshua Berne, Timur Doumler, Andrzej Krzemieński et al.,
    "Contracts for C++", <br>
    (<a href="https://isocpp.org/files/papers/P2900R11.pdf">"https://isocpp.org/files/papers/P2900R11.pdf"</a>).
    </li>
    <!--
    <a href="https://isocpp.org/files/papers/P2900R11.pdf"
       title="Joshua Berne, Timur Doumler, Andrzej Krzemieński et al., &ldquo;Contracts for C++&rdquo;">[P2900R11]</a>
    -->
    
<li>[P2969R0] — Timur Doumler, Ville Voutilainen, Tom Honermann, "Contract annotations are potentially-throwing" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2969r0.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2969r0.pdf</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2969r0.pdf"
       title="Timur Doumler, Ville Voutilainen, Tom Honermann, &ldquo;Contract annotations are potentially-throwing&rdquo;">[P2969R0]</a>
    --> 
 
    
<li>[P3081R0] — Herb Sutter, "Core safety Profiles: Specification, adoptability, and impact" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf"
       title="Herb Sutter, &ldquo;Core safety Profiles: Specification, adoptability, and impact&rdquo;">[P3081R0]</a>
    -->


<li>[P3100R1] — Timur Doumler, Gašper Ažman, Joshua Berne, "Undefined and erroneous behaviour is a contract violation" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3100r1.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3100r1.pdf</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3100r1.pdf"
       title="Timur Doumler, Gašper Ažman, Joshua Berne, &ldquo;Undefined and erroneous behaviour is a contract violation&rdquo;">[P3100R1]</a>
    -->

<li>[P3113R0] — Timur Doumler, "Contract assertions, the noexcept operator, and deduced exception specifications" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3113r0.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3113r0.pdf</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3113r0.pdf"
       title="Timur Doumler, &ldquo;Contract assertions, the noexcept operator, and deduced exception specifications&rdquo;">[P3113R0]</a>
    --> 
    
<li>[P3114R0] — Andrzej Krzemieński, "noexcept(contract_assert(_))" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3114r0.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3114r0.pdf</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3114r0.pdf"
       title="Andrzej Krzemieński, &ldquo;noexcept(contract_assert(_))&rdquo;">[P3114R0]</a>
    --> 

<li>[P3166R0] — Lewis Baker, "Static Exception Specifications" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3166r0.html">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3166r0.html</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3166r0.html"
       title="Lewis Baker, &ldquo;Static Exception Specifications&rdquo;">[P3166R0]</a>
    -->
 
<li>[P3205R0] — Gašper Ažman, Jeff Snyder, Andrei Zissu, Ben Craig, "Throwing from a <code>noexcept</code> function should be a contract violation." <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3205r0.pdf">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3205r0.pdf</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3205r0.pdf"
       title="Gašper Ažman, Jeff Snyder, Andrei Zissu, Ben Craig, &ldquo;Throwing from a noexcept function should be a contract violation.&rdquo;">[P3205R0]</a>
    --> 

<li>[P3471R2] — Konstantin Varlamov, Louis Dionne, "Standard library hardening" <br>
    (<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3471r2.html">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3471r2.html</a>).
    </li>
    <!-- 
    <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3471r2.html"
       title="Konstantin Varlamov, Louis Dionne, &ldquo;Standard library hardening&rdquo;">[P3471R2]</a>
    -->



</ul>



</body></html>
