<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese <span dir="ltr">&lt;<a href="mailto:s9jafroe@stud.uni-saarland.de" target="_blank">s9jafroe@stud.uni-saarland.de</a>&gt;</span> wrote:<br>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      
      I think most concerns about the current use of asserts would be
      resolved if the currently used asserts would be changed to a nicer
      definition which is independent of NDEBUG, and a second class of
      debugging asserts would be introduced, which is exclusively for
      expensive, redundant checks and is disabled by NDEBUG.<br></div></div></blockquote><div><br></div><div>Also, most assertion errors that happen to people running Bitcoin Core are not caused by software bugs but database corruption errors (usually due to unclean shutdown).<br>
<br></div>For example in case we detect missing/truncated block files or UTXO db consistency we should, instead of raising an assertion error, propose a -reindex - see also <a href="https://github.com/bitcoin/bitcoin/issues/2202">https://github.com/bitcoin/bitcoin/issues/2202</a> .<br>
<br></div><div class="gmail_quote">So instead of using assertions we need a fatal error function for those problems which are probably recoverable in a certain specific way. In principle starting a reindex wouldn&#39;t even need to take down the entire process (though that&#39;s easier for implementation due to cleanup and assumptions made).<br>
</div><div class="gmail_quote"><div><br>Wladimir<br></div></div><br></div></div>