<story><title>This should never happen</title><url>https://github.com/search?q=This+should+never+happen&amp;type=Code&amp;utf8=%E2%9C%93</url></story><parent_chain><item><author>Aaargh20318</author><text>It&amp;#x27;s also for cases when you &lt;i&gt;know&lt;/i&gt; it can&amp;#x27;t happen. For example, Java&amp;#x27;s String class has a method&lt;p&gt;&lt;pre&gt;&lt;code&gt;    public byte[] getBytes(String charsetName) throws UnsupportedEncodingException 
&lt;/code&gt;&lt;/pre&gt;
Since it can throw a checked exception you have to catch it, which generally is fine, but consider this case:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    someString.getBytes(&amp;quot;UTF-8&amp;quot;); 
&lt;/code&gt;&lt;/pre&gt;
This call can never fail (support for UTF-8 encoding is required in Java) but in my case I have to do something with the exception in the catch statement or our static code analysis tool will start complaining (and rightfully so). So that&amp;#x27;s where I&amp;#x27;ll log a &amp;#x27;can&amp;#x27;t happen error&amp;#x27;. It truly cannot happen.</text></item><item><author>ctdonath</author><text>It&amp;#x27;s a sub-pattern of &amp;quot;ain&amp;#x27;t got time for dat&amp;quot;. Developer &lt;i&gt;knows&lt;/i&gt; that condition should never happen, but is not inclined to prove it (as represented by coding type checking or other handling) yet realizes it shouldn&amp;#x27;t be ignored outright (if only to document the unproven condition in code, or to shut the compiler up about incompleteness warnings).</text></item><item><author>dzdt</author><text>&amp;quot;This should never happen&amp;quot; is a design pattern of defensive programming.  This is the same pattern for assert.&lt;p&gt;The usual use is to catch errors caused by misuse of a method.  There is some invariant that the method assumes but is not enforced by the type signature of the interface. So if something goes wrong in outside code, or someone tries to use the method incorrectly, the invariant is not satisfied.  When you catch such a problem, the current code context is FUBAR.  The question is how aggressively to bail out : spew errors to a log and proceed with some GIGO calculation?  Throw an exception?  Exit the program?</text></item></parent_chain><comment><author>jdmichal</author><text>Also in Java: Switching or if-else chains on an `enum`. It&amp;#x27;s still a good practice to include a final `else` or `default` case, but it should really never happen. Actually, inclusion of the `default` case will be &lt;i&gt;enforced&lt;/i&gt; by the compiler if it can detect a code path that doesn&amp;#x27;t return. [0]&lt;p&gt;&lt;pre&gt;&lt;code&gt;    enum Whatever { FOO, BAR }

    if (whatever == FOO) {
    } else if (whatever == BAR) {
    } else {
        &amp;#x2F;&amp;#x2F; Should never happen!
    }
&lt;/code&gt;&lt;/pre&gt;
[0] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;stackoverflow.com&amp;#x2F;questions&amp;#x2F;5013194&amp;#x2F;why-is-default-required-for-a-switch-on-an-enum-in-this-code&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;stackoverflow.com&amp;#x2F;questions&amp;#x2F;5013194&amp;#x2F;why-is-default-re...&lt;/a&gt;</text></comment>
<story><title>This should never happen</title><url>https://github.com/search?q=This+should+never+happen&amp;type=Code&amp;utf8=%E2%9C%93</url></story><parent_chain><item><author>Aaargh20318</author><text>It&amp;#x27;s also for cases when you &lt;i&gt;know&lt;/i&gt; it can&amp;#x27;t happen. For example, Java&amp;#x27;s String class has a method&lt;p&gt;&lt;pre&gt;&lt;code&gt;    public byte[] getBytes(String charsetName) throws UnsupportedEncodingException 
&lt;/code&gt;&lt;/pre&gt;
Since it can throw a checked exception you have to catch it, which generally is fine, but consider this case:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    someString.getBytes(&amp;quot;UTF-8&amp;quot;); 
&lt;/code&gt;&lt;/pre&gt;
This call can never fail (support for UTF-8 encoding is required in Java) but in my case I have to do something with the exception in the catch statement or our static code analysis tool will start complaining (and rightfully so). So that&amp;#x27;s where I&amp;#x27;ll log a &amp;#x27;can&amp;#x27;t happen error&amp;#x27;. It truly cannot happen.</text></item><item><author>ctdonath</author><text>It&amp;#x27;s a sub-pattern of &amp;quot;ain&amp;#x27;t got time for dat&amp;quot;. Developer &lt;i&gt;knows&lt;/i&gt; that condition should never happen, but is not inclined to prove it (as represented by coding type checking or other handling) yet realizes it shouldn&amp;#x27;t be ignored outright (if only to document the unproven condition in code, or to shut the compiler up about incompleteness warnings).</text></item><item><author>dzdt</author><text>&amp;quot;This should never happen&amp;quot; is a design pattern of defensive programming.  This is the same pattern for assert.&lt;p&gt;The usual use is to catch errors caused by misuse of a method.  There is some invariant that the method assumes but is not enforced by the type signature of the interface. So if something goes wrong in outside code, or someone tries to use the method incorrectly, the invariant is not satisfied.  When you catch such a problem, the current code context is FUBAR.  The question is how aggressively to bail out : spew errors to a log and proceed with some GIGO calculation?  Throw an exception?  Exit the program?</text></item></parent_chain><comment><author>masklinn</author><text>FWIW getBytes(Charset) doesn&amp;#x27;t throw, and there&amp;#x27;s a base set of charsets in StandardCharsets (1.7+):&lt;p&gt;&lt;pre&gt;&lt;code&gt;    someString.getBytes(StandardCharsets.UTF_8);
&lt;/code&gt;&lt;/pre&gt;
(Charset.forName doesn&amp;#x27;t throw either, StandardCharsets avoid stringly-typed code but it&amp;#x27;s not available on 1.6 so if you&amp;#x27;re still stuck there Charset.forName works)</text></comment>