My favorite example of a "this should never happen" error was when I got a call from a customer, who started the conversation by asking, "Who is Brian?".<p>I was caught a bit off guard, but I assumed the customer must know someone at the company, since Brian was the name of the previous electrical engineer/firmware programmer. So, I told them that Brian didn't work here any more, but was there anything that I could help them with? The customer said, "Well, the device says that I should call Brian". I was confused by this, and asked a lot of questions until I determined that the device was actually displaying "CALL BRIAN" on the LCD display.<p>This was quite unusual, and at first I didn't believe the customer, until he sent a picture of the device showing the message.<p>So, I dug into the code, and quickly found the "Call Brian" error condition. It was definitely one of those "this should never happen" cases. I presume that Brian had put that in during firmware development to catch an error case he was afraid might happen due to overwriting valid memory locations.<p>I got the device back, and found out that the device had a processor problem (I don't remember exactly what) that would write corrupted data to memory. So, really, it should never happen.<p>That particular device has now been in production for 10 years, and that is the only time that error has ever appeared.
"This should never happen" is a design pattern of defensive programming. This is the same pattern for assert.<p>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?
Using github to search like this reminds me of how a CS professor of mine would show the "best commit messages of the year" (homework was submitted via git) by looking for various patterns like all caps, all symbols, etc.<p><a href="http://www.slideshare.net/bsotomay/uchicago-cmsc-23300-the-best-commit-messages-of-2015" rel="nofollow">http://www.slideshare.net/bsotomay/uchicago-cmsc-23300-the-b...</a>
My favorite part is the Java project that has an exception class called ThisShouldNeverHappenException [1]. Only in Java would someone create an exception class for a condition that should never happen :)<p>[1] <a href="https://github.com/TheProjecter/propidle/blob/f0d5320e2a3d46f9fe7ea3c36fc071256e023234/src/com/googlecode/propidle/util/ThisShouldNeverHappenException.java" rel="nofollow">https://github.com/TheProjecter/propidle/blob/f0d5320e2a3d46...</a>
GitHub's search is pretty interesting: every time I refresh the search page it shows a different number of results: 18,401,830; 17,751,631; 15,995,799.<p>Which is anyways quite a lot of results, but then this search finds <i>ThisShouldNeverHappenException</i>, the string <i>"this should never happen"</i> and stuff like<p><pre><code> // *This* gets run before every test.
if (b > d) {
fail("XX *should never happen*");
}
</code></pre>
With quotations it's <i>only</i> about 500,000.
Sometimes you have to satisfy the compiler because it has less information about a situation than you do. Ideally this would be captured in the type system, but limitations (language, project, politics, time, etc) may prevent this. As another comment mentions, it's a kind of invariant check.<p>For example, based on external information you might know[1] that a condition inside of a loop will always be hit exactly one time. Your compiler or tools might not be able to determine that same thing. It may try to force you to do something like assign a value or whatever you did in that condition, that it can't guarantee has happened. In such a scenario, it might[2] make sense to have something like "this should never happen" after the loop, with a brief comment explaining why you've done this.<p>[1] I think this is the crux of the issue. We programmers often think we "know" something, but it might be an incorrect assumption. IMO part of being a good programmer is examining your assumptions at every step. The chasm is vast, between "the framework strongly guarantees X" and "the function that gets called before this one has done X already". The former is OK if you want to get work done, while the latter is much more brittle and possibly dangerous, depending on the level of coupling you're willing to accept.<p>[2] Nine times out of ten, a reorganization of the logic makes more sense. However, I do think there are scenarios where this pattern is the best choice given the options.
In my experience, "this should never happen" cases often are a sign of very brittle design that branches into many separate but nearly-identical paths, and could be simplified to remove them. The other thing it points to is bad error handling paths (assuming that an error could "never happen".)<p>Also funny to see Java being the most verbose as usual, with its ThisShouldNeverHappenException.java
This too: <a href="https://github.com/search?utf8=%E2%9C%93&q=no+idea+why+this+works&type=Code&ref=searchresults" rel="nofollow">https://github.com/search?utf8=%E2%9C%93&q=no+idea+why+this+...</a><p>:)
Not trolling here. I'm curious why this is getting so much attention. Isn't saying "this should never happen" just making an assertion about the behavior of your code? As far as the apparent inconsistencies in the code seen in the results go, is it really fair to judge a random piece of code from a random person (and completely out of context)? Don't we all have scratch/experimental/incomplete code hosted on our github accounts?
But what they mean is, 'This should never happen unless there's a serious problem upstream' and so these sorts of Asserts and Throws are actually very useful. Its all about 'Fail Fast'
I think thats just good common practice - the amounts of times I've seen that message when obviously I never expected to :)<p>This one is more worrying I suppose:
<a href="https://github.com/search?utf8=&q=FIXME&type=Code&ref=searchresults" rel="nofollow">https://github.com/search?utf8=&q=FIXME&type=Code&ref=search...</a>
I usually annotate should-never-happen asserts by the most plausible explanation how it _could_ happen, for the sake of some poor guy unlucky enough for having to debug my code.<p>E.g. "Should not happen — probably a bug in Apache Commons Math?"<p>Or "Shouldn't really happen, barring compiler bugs or cosmic rays"<p>As they told us, there is no such thing as probability of zero.
call error("in omatch: can't happen");
- Line from omatch routine on pg. 146 [1].<p>Snips from discussion in [1]: "We can expect problems, therefore, and should prepare for them. ... Garbage is bad enough, but garbage which is expected to contain a count to tell you how long it is can be much worse. ... The first time we ran this code it said 'can't happen' We got that message perhaps a hundred times in the process of adding the rest of the code... This experience speaks for itself; if you're going to walk a high-wire, use a net."<p>'Can't happen' is as much a pattern as 'Hello, World'... and it has the same genesis.<p>[1] Brian Kernighan, P.J. Plauger, 'Software Tools', Addison-Wesley 1976
One of the most common causes of failures are cases that the programmer never considered. Once of my favorite test coverage tools shows you missed branches and I find that invaluable.<p>My initial reaction was "oh no" but as I thought about it, this explicitly indicates that the programmer actually thought about a case.<p>And is it any different than what most of us do in our unit tests? If we're expecting an exception that isn't thrown or the wrong exception is thrown, we force a test failure.<p>One of the goals our team is working towards is more robust and complete metric and log collection. We specifically want to capture exceptions that make it to the application server for analysis, but this assumes that the developer has a) considered all cases and b) caught intermediate exceptions and continued processing (or abort).
There are better (aka more creative) ways of inducing rage in fellow cow-orkers. <a href="https://twitter.com/noahlz/status/709961243277332482" rel="nofollow">https://twitter.com/noahlz/status/709961243277332482</a>
<p><pre><code> void(int a, int b)
{
const int i = 0;
int result = a + b;
if (i > 0)
{
// This will never happen ;)
result = result / 0;
}
}</code></pre>
One product I worked on a number of years ago had a CantHappen() function with a simple implementation. It displayed this message box:<p><pre><code> You are not here.
</code></pre>
Another message was in the Mac installer when there wasn't room to install:<p><pre><code> Your hard disk is too small.
</code></pre>
That's the complete text of both messages, and yes, it displayed them <i>to the customer</i>. <sigh><p>After seeing these, I started going through the code and found a bunch of other rude, confusing, or jargony messages. It actually turned into a fun little project cleaning these up!
"wtf": <a href="https://github.com/search?utf8=%E2%9C%93&q=%22wtf%22&type=Code&ref=searchresults" rel="nofollow">https://github.com/search?utf8=%E2%9C%93&q=%22wtf%22&type=Co...</a><p>Anyway, if you read commits in Linux you'd find a lot of fuck in there. Quite amusing.<p>When I was an intern, I loved looking at MXR to find words like fuck: <a href="http://mxr.mozilla.org/mozilla-central/search?string=fuck" rel="nofollow">http://mxr.mozilla.org/mozilla-central/search?string=fuck</a>
There's almost twice as many "should not get here" results[1], which I think would mostly be used in the same situation, in case someone is looking for more.<p>1: <a href="https://github.com/search?utf8=%E2%9C%93&q=should+not+get+here&type=Code&ref=searchresults" rel="nofollow">https://github.com/search?utf8=%E2%9C%93&q=should+not+get+he...</a>
I remember one place I worked had an error thrown that showed as hex code "48 45 4C 4C 4E 4F". As far as I know it only occurred once in test when someone did something epically stupid as a patch to the code preceding it. We removed the patch and never saw the code again. Have no real clue who put it in there, as code control was a later addition.
Cray Research had a linker named SEGLDR that was written in Fortran, whose STOP statement allows an optional string message, and so it was used for run-time assertion checking like<p>IF(.NOT.CHECK()) STOP 'xxx'<p>Anyway, somebody (not me) got into trouble when Very Serious Customers were offended by seeing the occasional STOP DAMN message at link time.
A related search I like is "why does this work": <a href="https://github.com/search?utf8=%E2%9C%93&q=%22why+does+this+work%22&type=Code&ref=searchresults" rel="nofollow">https://github.com/search?utf8=%E2%9C%93&q=%22why+does+this+...</a>
I think "should not get here" highlights this point better<p><a href="https://github.com/search?utf8=%E2%9C%93&q=should+not+get+here&type=Code&ref=searchresults" rel="nofollow">https://github.com/search?utf8=%E2%9C%93&q=should+not+get+he...</a>
C still in the lead for: why is this happening
<a href="https://github.com/search?utf8=%E2%9C%93&q=why+is+this+happening&type=Code&ref=searchresults" rel="nofollow">https://github.com/search?utf8=%E2%9C%93&q=why+is+this+happe...</a>
And the related Log.wtf() on Android:<p><a href="http://developer.android.com/reference/android/util/Log.html#wtf(java.lang.String,%20java.lang.Throwable)" rel="nofollow">http://developer.android.com/reference/android/util/Log.html...</a>
Since so many people obviously need this functionality, I've created a reusable Python version here: <a href="https://github.com/vitaut/neverhappen" rel="nofollow">https://github.com/vitaut/neverhappen</a>
By far not as popular as foo
<a href="https://github.com/search?utf8=%E2%9C%93&q=foo&type=Code&ref=searchresults" rel="nofollow">https://github.com/search?utf8=%E2%9C%93&q=foo&type=Code&ref...</a>
Maybe even more interesting:<p><a href="https://github.com/search?utf8=%E2%9C%93&q=%22no+idea+why+this+works%22&type=Code&ref=searchresults" rel="nofollow">https://github.com/search?utf8=%E2%9C%93&q=%22no+idea+why+th...</a>
I find this more entertaining :
<a href="https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=fuck" rel="nofollow">https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=fu...</a>
Reminds me of the "Six Stages of Debugging": <a href="http://plasmasturm.org/log/6debug/" rel="nofollow">http://plasmasturm.org/log/6debug/</a>
This is awesome.<p><pre><code> public class ThisShouldNeverHappenException extends RuntimeException {
public ThisShouldNeverHappenException(Exception cause) {
super(cause);
}
}</code></pre>
Best one is<p>/<i></i>
* This should never happen exception. Use in situation that really shouldn't happen...NEVER
*
*
*/
public class NeverHappenException extends RuntimeException {
The shocking part is the number of times:<p>"This should never happen": 823,044
This should never happen: 16,946,357
vs.
"This is screwed up": 59
This is screwed up: 876,393
Could be that some of the "This should never happen" can be deduced by optimizing compilers and never exist in assembly?
Not talking about the interpreted stuff.