<blockquote>
<p>Because they know things will crash if they do</p>
</blockquote>
<p>They will crash or do whatever undefined behaviour either way.</p>
<blockquote>
<p>Thats a specious argument. Since most programmers fix crashing errors that occur every time the program runs, the errors MUST depend on user input otherwise they would be fixed if they occurred all the time. So unless you apply analysis or exhaustive testing user input can always expose programming errors, so if the program can politely decline to perform the user operation and keep running its better than crashing.</p>
</blockquote>
<p>No, these assertions are meant only for programming error, using them for release-build control flow is not advised. See from the docs below:</p>
<blockquote>
<p>The g_return family of macros (g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), g_return_val_if_reached()) should only be used for programming errors, a typical use case is checking for invalid parameters at the beginning of a public function. They should not be used if you just mean "if (error) return", they should only be used if you mean "if (bug in program) return". The program behavior is generally considered undefined after one of these checks fails. They are not intended for normal control flow, only to give a perhaps-helpful warning before giving up.</p>
</blockquote>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany-plugins/commit/109b8d079a59ba35e8aba5da960fc5b10f03ea7f#commitcomment-23748190">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ93RWniUPdNMcYrHNrCddrM7F6Vfks5sZ5G5gaJpZM4O8Uoj">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJzEusWAh7OMgTuFj-zCKXIGjEVIBks5sZ5G5gaJpZM4O8Uoj.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany-plugins/commit/109b8d079a59ba35e8aba5da960fc5b10f03ea7f#commitcomment-23748190"></link>
  <meta itemprop="name" content="View Commit"></meta>
</div>
<meta itemprop="description" content="View this Commit on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany-plugins","title":"geany/geany-plugins","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany-plugins"}},"updates":{"snippets":[{"icon":"PERSON","message":"@codebrainz on 109b8d0: \u003e Because they know things will crash if they do\r\n\r\nThey will crash or do whatever undefined behaviour either way.\r\n\r\n\u003eThats a specious argument. Since most programmers fix crashing errors that occur every time the program runs, the errors MUST depend on user input otherwise they would be fixed if they occurred all the time. So unless you apply analysis or exhaustive testing user input can always expose programming errors, so if the program can politely decline to perform the user operation and keep running its better than crashing.\r\n\r\nNo, these assertions are meant only for programming error, using them for release-build control flow is not advised. See from the docs below:\r\n\r\n\u003e The g_return family of macros (g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), g_return_val_if_reached()) should only be used for programming errors, a typical use case is checking for invalid parameters at the beginning of a public function. They should not be used if you just mean \"if (error) return\", they should only be used if you mean \"if (bug in program) return\". The program behavior is generally considered undefined after one of these checks fails. They are not intended for normal control flow, only to give a perhaps-helpful warning before giving up. "}],"action":{"name":"View Commit","url":"https://github.com/geany/geany-plugins/commit/109b8d079a59ba35e8aba5da960fc5b10f03ea7f#commitcomment-23748190"}}}</script>