title: If you're in the "we don't use exceptions" camp, then how do you use the standard library?
body: <p><strong>Note:</strong> I'm not playing the devil's advocate or anything like that here - I'm just genuinely curious since I'm not in this camp myself.</p>
  
  <p>Most types in the standard library have either mutating functions that can throw exceptions (for instance if memory allocation fails) or non-mutating functions that can throw exceptions (for instance out of bounds indexed accessors). In addition to that, many free functions can throw exceptions (for instance <code>operator new</code> and <code>dynamic_cast&lt;T&amp;&gt;</code>).</p>
  
  <p>How do you <em>practically</em> deal with this in the context of "we don't use exceptions"?</p>
  
  <ul>
  <li><p>Are you trying to <em>never</em> call a function that can throw? (I can't see how that'd scale, so I'm very interested to hear how you accomplish this if this is the case)</p></li>
  <li><p>Are you ok with the standard library throwing and you treat "we don't use exceptions" as "we never <em>throw</em> exceptions from <em>our</em> code and we never <em>catch</em> exceptions from <em>other's</em> code"?</p></li>
  <li><p>Are you disabling exception handling altogether via compiler switches? If so, how do the exception-throwing parts of the standard library work?</p></li>
  <li><p><strong>EDIT</strong> Your constructors, can they fail, or do you by convention use a 2-step construction with a dedicated init function that can return an error code upon failure (which the constructor can't), or do you do something else?</p></li>
  </ul>
  
  <p><strong>EDIT</strong> Minor clarification 1 week after the inception of the question... Much of the content in comments and questions below focus on the <em>why</em> aspects of exceptions vs "something else". My interest is not in that, but <em>when</em> you choose to do "something else", <em>how</em> do you deal with the standard library parts that <em>do</em> throw exceptions?</p>