
This should never happen - Rygu
https://github.com/search?q=This+should+never+happen&type=Code&utf8=%E2%9C%93
======
FiatLuxDave
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?".

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.

This was quite unusual, and at first I didn't believe the customer, until he
sent a picture of the device showing the message.

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.

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.

That particular device has now been in production for 10 years, and that is
the only time that error has ever appeared.

~~~
return0
Did you tell brian?

~~~
FiatLuxDave
Of course I did. He didn't remember putting in that error condition, but he
loved the story!

~~~
viperscape
He doesn't remember? That's scary hah. Seems like something worth remembering.
Great story, made me laugh

~~~
sliverstorm
Do _you_ remember all the trap code you've ever written?

~~~
alttab
Traps are for the insecure. I just write to memory without checking bounds or
asking questions. No one has ever tried to call me.

~~~
amagumori
"Hi alttab, i tried to use your program but it closed and displayed a message
saying 'segregation fault' or something...i'm not a racist, i love all people,
please give me a call back"

------
dzdt
"This should never happen" is a design pattern of defensive programming. This
is the same pattern for assert.

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?

~~~
ctdonath
It's a sub-pattern of "ain't got time for dat". Developer _knows_ 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't be
ignored outright (if only to document the unproven condition in code, or to
shut the compiler up about incompleteness warnings).

~~~
Aaargh20318
It's also for cases when you _know_ it can't happen. For example, Java's
String class has a method

    
    
        public byte[] getBytes(String charsetName) throws UnsupportedEncodingException 
    

Since it can throw a checked exception you have to catch it, which generally
is fine, but consider this case:

    
    
        someString.getBytes("UTF-8"); 
    

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's where I'll log a 'can't happen error'. It truly cannot happen.

~~~
wyager
getBytes is poorly designed. In a safety-oriented language like Haskell or
Rust, the set of encodings would be represented as an ADT (which forms a
closed set) or s Typeclass (open set). All possible type-correct encoding
arguments would be safe.

~~~
MichaelBurge
Speaking to the Haskell part:

An ExceptT or Maybe monad for handling encoding errors feels a lot like
throwing exceptions, although they are less disruptive than exceptions. I'd
probably represent a decoder as a function with type ByteString -> ErrorT
ParseError m Text, which is neither an ADT or Typeclass. It's a 3rd solution.
Either that or an Attoparsec parser, which is probably equivalent. An encoder
seems like it shouldn't fail at all, but if it eventually forks out to one of
the C locale functions I can see it throwing errors too.

Meanwhile, in the real world, Data.Text.Encoding uses a 4th solution
implementing decodeUtf8With and encodeUtf8 that ultimately represents the
UTF-8 encoding as a pair of FFI functions with these signatures:

    
    
      foreign import ccall unsafe "_hs_text_decode_utf8"   c_decode_utf8
          :: MutableByteArray# s -> Ptr CSize
          -> Ptr Word8 -> Ptr Word8 -> IO (Ptr Word8)
    

and this one:

    
    
      foreign import ccall unsafe "_hs_text_encode_utf8" c_encode_utf8
          :: Ptr (Ptr Word8) -> ByteArray# -> CSize -> CSize -> IO ()
    

text-icu also ultimately represents an encoding as an opaque pointer returned
by the ICU library, and works in the IO monad. So it too could fail in similar
ways. Errors throw an exception of type ICUError, which the caller can catch
using the 'catch' function from Control.Exception.

The encoding library does use typeclasses like you suggest, but I'm not sure
anybody uses it. Sometimes people drop in #haskell and complain about that
library, and the response is usually "don't use that; use the one in
Data.Text.Encoding instead".

I don't use Rust, but if the language is at all practical, I imagine they
shuttle their equivalent of pointers and bytestrings around and depend on
foreign C libraries and locales just the same. Probably they don't want to
change the core library every time the Unicode Consortium publishes a new
encoding scheme, so I can't imagine them exposing only a closed type.

So, looking purely at the signature and comparing it to examples from a
language you suggested, it doesn't appear to be poorly designed at all. It's
exactly what I would expect and want in any language, and the library
consensus seems to agree. I think you're just imagining the grass being
greener on the other side.

~~~
steveklabnik
In Rust, our main two string types are String and &str, which are both UTF-8
encoded. For interoperability with other things, we have additional types that
you can convert to/from.
[http://andrewbrinker.github.io/blog/2016/03/27/string-
types-...](http://andrewbrinker.github.io/blog/2016/03/27/string-types-in-
rust/) is a recent overview in a blog post.

------
paulkaplan
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.

[http://www.slideshare.net/bsotomay/uchicago-
cmsc-23300-the-b...](http://www.slideshare.net/bsotomay/uchicago-
cmsc-23300-the-best-commit-messages-of-2015)

~~~
georgestephanis
My favorite commit message of all time:

[https://core.trac.wordpress.org/changeset/26851](https://core.trac.wordpress.org/changeset/26851)

\---

The Pinking Shears stir from their slumber, awakened by what may seem, to
those innocent in the ways of The Shears, a triviality, a nothing-of-
consequence. But there are consequences indeed for recklessly trailing your
whitespace. Naturally, they a dire!

One, two! One, two! And through and through

The Pinking Shears went snicker-snack!

They plucked your tail and with your space

They went sniksnuking back.

Let me tell you, that can be uncomfortable, so always pre-sniksnuk your
trailing whites. May The Shears be with you.

~~~
moheeb
It doesn't surprise me that someone that would make a change like that would
leave a comment like that.

They removed a trailing space from a comment! They have plenty of free time to
write witty check-in comments.

~~~
OJFord
I definitely aim to remove things like that, but I tend to sneak it in with
something else (partly because the fix likely came as soon as I used an editor
properly configured to strip it).

I'm not sure if that's a 'bad' practice or just not the purest. But I don't
think removing trailing comment space is bad in itself. As above, it probably
didn't take any time at all; done automatically by a well-configured editor.

------
BinaryIdiot
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 :)

[1]
[https://github.com/TheProjecter/propidle/blob/f0d5320e2a3d46...](https://github.com/TheProjecter/propidle/blob/f0d5320e2a3d46f9fe7ea3c36fc071256e023234/src/com/googlecode/propidle/util/ThisShouldNeverHappenException.java)

~~~
stinos
Not just Java. I've seen similar classes in C++ and C# to indicate things
which should never occur/are clearly bad programmer mistakes/... Think
InternalErrorException/DevFailedError etc. Sometimes it's just a sane thing to
do, and using such names means you don't need to write the dreaded 'should
never happen' comment manually anymore.

~~~
Kristine1975
Isn't that what assertions are for?

~~~
Karunamon
Assertions can be disabled at runtime. If your goal is to call out the fact
that something has gone fundamentally wrong with your program's state, an
exception is the way to go.

------
wimagguc
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.

Which is anyways quite a lot of results, but then this search finds
_ThisShouldNeverHappenException_ , the string _" this should never happen"_
and stuff like

    
    
        // *This* gets run before every test.
        if (b > d) {
            fail("XX *should never happen*");   
        }
    

With quotations it's _only_ about 500,000.

~~~
BenoitP
HyperLogLog[1] will do that. You can find it in Redis, Lucene; and I suspect
it is also hidden behind BigQuery's count(distinct X)s.

[1]
[https://en.wikipedia.org/wiki/HyperLogLog](https://en.wikipedia.org/wiki/HyperLogLog)

~~~
sammoth
What part of the algorithm would cause the number to change significantly
every time you run the query?

~~~
BenoitP
All shards compute their own, and send the result in a non deterministic
order. My explanation is that the merge part of HLL depends on the order.

Line 95 of this method [1] from this implementation [2] shows a max(mask(x),
mask(y)), which is not associative but is a close proxy to max()(which is
associative).

[1] [https://github.com/addthis/stream-
lib/blob/af045cb4199959c07...](https://github.com/addthis/stream-
lib/blob/af045cb4199959c07fb4422e605573e180491191/src/main/java/com/clearspring/analytics/stream/cardinality/RegisterSet.java#L87)

[2] [https://github.com/addthis/stream-
lib/blob/master/src/main/j...](https://github.com/addthis/stream-
lib/blob/master/src/main/java/com/clearspring/analytics/stream/cardinality/HyperLogLog.java)

------
usea
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.

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.

[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.

[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.

------
userbinator
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".)

Also funny to see Java being the most verbose as usual, with its
ThisShouldNeverHappenException.java

~~~
merb
Mostly there is no need for "ThisShouldNeverHappenException" since java has a
IllegalStateException

~~~
manyxcxi
To be fair, someone writing a ThisShouldNeverHappenException may not be the
kind of developer that knows about an IllegalStateException.

~~~
merb
Actually they at least need to know about a RuntimeException then.

So that would've worked, too:

    
    
        throw new RuntimeException("This should never happen!");
    

There would've been a difference between a Exception and a RuntimeException.

Also sometimes this kind of RuntimeException happens when you convert one type
into another and want to explictly call all cases something like that:

    
    
        interface A
        class AA implements A
        class AB implements A
        
        if (x instanceof AA) {}
        else if (x instanceof AB) {} 
        else { throw new IllegalStateException; } 
    

It's sometimes better to explicitly call all states instead of using the last
else for the AB branch, since sometimes this will be extended later or the
compiler would've throw an error since you have a return inside the if or else
if. Btw. Kotlin and Scala won't have this problem due to pattern matching.

------
ZeroGravitas
Apparently things-that-shouldn't-happen happen 10x more in C code than the
next nearest language.

~~~
BinaryIdiot
I didn't even notice that. Good observation. I wonder if that's simply because
C is a lot older and may just have a lot more dead code or this type of code
or something else entirely.

~~~
speeder
I am a C lover.

It is because C has no exception handling, and C coders still want to be sure.

For example once I had a game where I ended putting a couple "should never
happen" in my code related to some OS stuff, and... the "should never happen"
happened once, after figuring how to reproduce it, it was a driver bug (or
something like that, happened years ago, I don't remember the details anymore,
only remember that it went away after I switched from Alsa to OSS4 on my Linux
box).

EDIT: should never happen is good against compiler bugs too, I've seen my fair
share of them.

------
cbaleanu
This too:
[https://github.com/search?utf8=%E2%9C%93&q=no+idea+why+this+...](https://github.com/search?utf8=%E2%9C%93&q=no+idea+why+this+works&type=Code&ref=searchresults)

:)

------
davesque
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?

------
codeulike
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'

------
daniel_iversen
I think thats just good common practice - the amounts of times I've seen that
message when obviously I never expected to :)

This one is more worrying I suppose:
[https://github.com/search?utf8=&q=FIXME&type=Code&ref=search...](https://github.com/search?utf8=&q=FIXME&type=Code&ref=searchresults)

------
atemerev
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.

E.g. "Should not happen — probably a bug in Apache Commons Math?"

Or "Shouldn't really happen, barring compiler bugs or cosmic rays"

As they told us, there is no such thing as probability of zero.

------
pjmorris
call error("in omatch: can't happen"); \- Line from omatch routine on pg. 146
[1].

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."

'Can't happen' is as much a pattern as 'Hello, World'... and it has the same
genesis.

[1] Brian Kernighan, P.J. Plauger, 'Software Tools', Addison-Wesley 1976

------
saint-loup
Previous noteworthy Github searches, found via hn.algolia.com :

[https://github.com/search?q=ugly+hack&ref=cmdform&type=Code](https://github.com/search?q=ugly+hack&ref=cmdform&type=Code)

[https://github.com/search?utf8=%E2%9C%93&q=filename%3Aid_rsa...](https://github.com/search?utf8=%E2%9C%93&q=filename%3Aid_rsa&type=Code&ref=searchresults)

[https://github.com/search?p=3&q=extension%3Aphp+mysql_query+...](https://github.com/search?p=3&q=extension%3Aphp+mysql_query+%24_GET&ref=searchresults&type=Code)

------
paul_milovanov
Search for "WTF", results by language

C++ 2.4M C 400K Java 150K ...

Sounds about right.

~~~
misframer
Also interesting considering there are over twice as many Java repositories
(>200,000) as C++ (<90,000) [0].

[0] [http://githut.info/](http://githut.info/)

------
cptskippy
This is what you throw when your padLeft webservice call fails.

------
smoyer
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.

My initial reaction was "oh no" but as I thought about it, this explicitly
indicates that the programmer actually thought about a case.

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.

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).

------
maxaf
There are better (aka more creative) ways of inducing rage in fellow cow-
orkers.
[https://twitter.com/noahlz/status/709961243277332482](https://twitter.com/noahlz/status/709961243277332482)

------
bryanrasmussen
[https://github.com/search?utf8=%E2%9C%93&q=Why+does+this+hap...](https://github.com/search?utf8=%E2%9C%93&q=Why+does+this+happen&type=Code&ref=searchresults)

~~~
nxzero
^^ Above links to a "Why do this always happen" search on Github likely to
express that if something that should never happens occurs, then you need to
understand why it happened, which is often hard, since it never happens. Often
solution is to be able to reproduce a bug by being able to playback what
happened.

EDIT: Ha, turns out the link is just an attempt to prove that bugs that should
never happen occur ten times more in C... Which is questionable.

------
w8rbt

        void(int a, int b)
        {
            const int i = 0;
            int result = a + b;
            if (i > 0)
            {
                // This will never happen ;)
                result = result / 0;
            }
        }

------
Stratoscope
One product I worked on a number of years ago had a CantHappen() function with
a simple implementation. It displayed this message box:

    
    
      You are not here.
    

Another message was in the Mac installer when there wasn't room to install:

    
    
      Your hard disk is too small.
    

That's the complete text of both messages, and yes, it displayed them _to the
customer_. <sigh>

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!

------
yeukhon
"wtf":
[https://github.com/search?utf8=%E2%9C%93&q=%22wtf%22&type=Co...](https://github.com/search?utf8=%E2%9C%93&q=%22wtf%22&type=Code&ref=searchresults)

Anyway, if you read commits in Linux you'd find a lot of fuck in there. Quite
amusing.

When I was an intern, I loved looking at MXR to find words like fuck:
[http://mxr.mozilla.org/mozilla-
central/search?string=fuck](http://mxr.mozilla.org/mozilla-
central/search?string=fuck)

------
kbenson
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.

1:
[https://github.com/search?utf8=%E2%9C%93&q=should+not+get+he...](https://github.com/search?utf8=%E2%9C%93&q=should+not+get+here&type=Code&ref=searchresults)

------
insulanian
C#: 58355, F#: 464, Haskel: 6

~~~
nograpes
I wonder if there is a way to calculate the denominator for each of those? The
proportion would be a much more compelling argument.

~~~
masklinn
[http://githut.info](http://githut.info)

------
protomyth
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.

------
pklausler
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

IF(.NOT.CHECK()) STOP 'xxx'

Anyway, somebody (not me) got into trouble when Very Serious Customers were
offended by seeing the occasional STOP DAMN message at link time.

------
JohnTHaller
A related search I like is "why does this work":
[https://github.com/search?utf8=%E2%9C%93&q=%22why+does+this+...](https://github.com/search?utf8=%E2%9C%93&q=%22why+does+this+work%22&type=Code&ref=searchresults)

------
mictlann
"Testing this shit" -> We’ve found 129,140 code results
[https://github.com/search?utf8=%E2%9C%93&q=Testing+this+shit...](https://github.com/search?utf8=%E2%9C%93&q=Testing+this+shit&type=Code&ref=searchresults)

------
nkhumphreys
I think "should not get here" highlights this point better

[https://github.com/search?utf8=%E2%9C%93&q=should+not+get+he...](https://github.com/search?utf8=%E2%9C%93&q=should+not+get+here&type=Code&ref=searchresults)

------
shimon_e
C still in the lead for: why is this happening
[https://github.com/search?utf8=%E2%9C%93&q=why+is+this+happe...](https://github.com/search?utf8=%E2%9C%93&q=why+is+this+happening&type=Code&ref=searchresults)

------
js2
And the related Log.wtf() on Android:

[http://developer.android.com/reference/android/util/Log.html...](http://developer.android.com/reference/android/util/Log.html#wtf\(java.lang.String,%20java.lang.Throwable\))

------
vitaut
Since so many people obviously need this functionality, I've created a
reusable Python version here:
[https://github.com/vitaut/neverhappen](https://github.com/vitaut/neverhappen)

------
Twisell
By far not as popular as foo
[https://github.com/search?utf8=%E2%9C%93&q=foo&type=Code&ref...](https://github.com/search?utf8=%E2%9C%93&q=foo&type=Code&ref=searchresults)

------
logicallee
Maybe even more interesting:

[https://github.com/search?utf8=%E2%9C%93&q=%22no+idea+why+th...](https://github.com/search?utf8=%E2%9C%93&q=%22no+idea+why+this+works%22&type=Code&ref=searchresults)

~~~
swehner
Or "How did this ever work?"

[https://github.com/search?utf8=%E2%9C%93&q=%22How+did+this+e...](https://github.com/search?utf8=%E2%9C%93&q=%22How+did+this+ever+work%22&type=Code&ref=searchresults)

------
heyitskevin
I wish we could sort by most starred to see what popular repositories have
code like this.

------
shade23
I find this more entertaining :
[https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=fu...](https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=fuck)

~~~
Cyph0n
That jab at Sun haha!

------
dc2
[https://github.com/search?utf8=%E2%9C%93&q=%22this+is+so+bro...](https://github.com/search?utf8=%E2%9C%93&q=%22this+is+so+broken%22&type=Code&ref=searchresults)

------
jballanc
Reminds me of the "Six Stages of Debugging":
[http://plasmasturm.org/log/6debug/](http://plasmasturm.org/log/6debug/)

------
mdjt
if happens: print "shit, that wasn't supposed to happen"

~~~
mrspeaker
Never ever EVER put bad language in any unexpected error cases or logs - even
as you're developing it... it WILL somehow magically make its way to
production, and it WILL appear!

~~~
kagamine
I remind myself frequently not to swear in code as I am quite juvenile on a
normal day. If I'm struggling I'll just make up a word, so that if it ever
happens that someone else sees it I can say it is an acronym but that I have
conveniently forgotten for what.

~~~
bryanrasmussen
You could always put a "this should never happen" right before the swear words
so they know it wasn't your fault.

~~~
kagamine
But there's a risk I'll become stuck in an infinite loop of writing shit! this
should never happen shit! this should never happen shit! ...

and so on. Still it would be a change from writing bad code.

~~~
bryanrasmussen
Wow, deja-vu, this is just what happened to me one time when I was working on
a new booking system for a hotel.

I was working on site over the winter season when the hotel was closed down, a
lovely old hotel high up in the Rockies. Every day I sat down and wanted to
write some brilliant code but all I ever ended up writing was the same comment

All objects and no functions makes Jack a dull boy. over and over again.

Drove me quite mad actually.

Sometimes I feel like I'm still there.

------
jroseattle
This is awesome.

    
    
       public class ThisShouldNeverHappenException extends RuntimeException {
          public ThisShouldNeverHappenException(Exception cause) {
              super(cause);
          }
       }

------
onetimePete
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.

------
ninjakeyboard
IllegalStateException already exists. Why would people make their own?

------
xydac
Best one is

/ __* This should never happen exception. Use in situation that really shouldn
't happen...NEVER * * */ public class NeverHappenException extends
RuntimeException {

------
justspamjustin
todo: stuff
[https://github.com/search?utf8=%E2%9C%93&q=todo+stuff&type=C...](https://github.com/search?utf8=%E2%9C%93&q=todo+stuff&type=Code&ref=searchresults)
todo: meh
[https://github.com/search?utf8=%E2%9C%93&q=todo+meh&type=Cod...](https://github.com/search?utf8=%E2%9C%93&q=todo+meh&type=Code&ref=searchresults)

------
ben_pr
The shocking part is the number of times:

"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

------
z3t4
At least make the error say WHY it should never happen.

------
raldi
If you work for a big company, search for this string in your bug-ticketing
system to see example logs from all the times these lines are triggered.

------
INTPenis
I remember using the comment "Craw! Polly shouldn't be!" instead, as a homage
to a specific Simpsons episode. :)

------
nevir
The thing is, we should be applauding people for many of these assertions. At
least when they're throwing errors

------
dumaspere
This reminds me of the sage advice, "Never check for a condition that you
don't know how to handle."

------
rubinho_
The best thing is that someone made a 'ThisShouldNeverHappenException'.

+1

------
cgtyoder
I prefer using CANTHAPPEN in the comment - easier to grep for.

------
nly
I'm a big fan of 'DO NOT MERGE' in git logs

~~~
danvideo
most of those probably tack on an "until..."

------
danvideo
Why no Ruby results?

------
pgtruesdell
As usual, these submissions from Github searches like this are just sad.

------
amelius
assert(false);

~~~
Kristine1975
__builtin_unreachable();

~~~
qb45
That's a disaster waiting to happen. See docs.

------
lilbobbytables
aaand naturally javascript is right up there in the top languages where this
is found.

~~~
jnbiche
And C is at the very top. Should we now proceed to heap scorn upon C
programmers?

