title: How to check for and handle precondition violations?
body: <p>C++20 is delivering some amazing new features around contracts - which for templates is going to make life much better - where constraints around types or other compile-time requirements can be baked into the template definition and enforced with decent diagnostics by the compiler.  Yay!</p>
  
  <p>However, I'm very concerned by the push towards terminating unconditionally when a runtime precondition violation occurs.</p>
  
  <p><a href="https://en.cppreference.com/w/cpp/language/attributes/contract" rel="nofollow noreferrer">https://en.cppreference.com/w/cpp/language/attributes/contract</a></p>
  
  <blockquote>
    <p>A program may be translated with one of two violation continuation
    modes:</p>
    
    <p>off (default if no continuation mode is selected): after the execution
    of the violation handler completes, std::terminate is called; on:
    after the execution of the violation handler completes, execution
    continues normally. Implementations are encouraged to not provide any
    programmatic way to query, set, or modify the build level or to set or
    modify the violation handler.</p>
  </blockquote>
  
  <p>I've written extensive user-facing software which traps all exceptions to a core execution loop where errors are logged and the user is informed of the failure.</p>
  
  <p>In many cases, the user is better off saving if possible and exiting, but in many other cases, the error can be addressed by changing something in the design / data file they're working on.</p>
  
  <p>This is to say - simply by altering their design (e.g. a CAD design) - the operation they wished to perform will now succeed.  E.g. it's possible that the code was executed with too tight of a tolerance which micomputed a result based on that.  Simply rerunning the procedure after changing tolerance would succeed (the offending precondition somewhere in the underlying code would no longer be violated).</p>
  
  <p>But the push to make preconditions simply terminate and have no capacity to trap such an error and retry the operation?  This sounds like a serious degradation in feature set to me.  Admittedly, there are domains in which this is exactly desirable.  Fail fast, fail early, and for preconditions or postconditions, the problem is in the way the code is written, and the user cannot remedy the situation.</p>
  
  <p>But... and this is a big but... most software executes against an unknown data set that is supplied at runtime - to claim that all software must terminate and that there is no way that a user can be expected to rectify the situation seems to be to be bizarre.</p>
  
  <p>Herb Sutter's discussion at the ACCU seems to be aligned strongly with the perspective that precondition &amp; postcondition violations are simply terminate conditions:</p>
  
  <p><a href="https://www.youtube.com/watch?v=os7cqJ5qlzo" rel="nofollow noreferrer">https://www.youtube.com/watch?v=os7cqJ5qlzo</a></p>
  
  <p>I'm looking for what other C++ pros are thinking from whatever your experiences coding informs you?</p>
  
  <p>I know that many projects disallow exceptions.  If you're working on one such project, does that mean you write your code to simply terminate whenever invalid input occurs?  Or do you back out using error states to some parent code point that is able to continue in some way?</p>
  
  <p>Maybe more to the point - maybe I'm misunderstanding the nature of the intent of C++20 runtime contracts are intended for?</p>
  
  <p>Please keep this civil - and if your suggestion is to close this - perhaps you could be so kind as to point to a more appropriate forum for this discussion?</p>
  
  <p>Most generally, I'm trying to answer, to my satisfaction:</p>
  
  <p><strong>How to check for and handle precondition violations (using best possible practices)?</strong></p>