Why no Ruby results?
This should never happen
151–160 of 214 posts
Re: This should never happen
#152I'm a big fan of 'DO NOT MERGE' in git logs
most of those probably tack on an "until..."
Re: This should never happen
#153My 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 hel…
You should have kept that message. Much more authentic and refreshing ;)
Re: This should never happen
#154Using 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...
My favorite commit message of all time: 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 snick…
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.
Re: This should never happen
#155Earlier quoted context omitted.
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).
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 so…
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.
Re: This should never happen
#156Earlier quoted context omitted.
Also in Java: Switching or if-else chains on an `enum`. It'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 enforced by the compiler if it can detect a code path that doesn't return. [0] enum Whatever { FOO, BAR } if (whatever == FOO) { } else if (whatever == BAR) { } else { // Should never happen! } [0] http://st…
This can happen when some other developer adds to your enum not knowing about the use.
[deleted]
Re: This should never happen
#157Earlier quoted context omitted.
What's interesting is that (as described in the present top comment on this article, about "CALL BRIAN"), if the abstraction of "type safety" is leaky (as it is , e.g. in the presence of memory or hardware errors), this kind of paranoia can actually have real-world benefits even though you can prove the impossibility of the code running using static analysis. Sometimes the important artifact is the executable in the…
There is nothing preventing modeling the contextual environment within static analysis. Static analysis/type systems help the programmer draw the line between the known and the unknown. Some conditions are just not practical or efficient to check for. However for the context you use it within you can make certain guarantees about the code. This is still incredibly useful even though it doesn't guarantee an error can…
And how do you verify that your checksum-verifying code hasn't been corrupted with cosmic rays?
The real world is messy. We can mitigate that, but we can never have mathematical purity.
Re: This should never happen
#158[deleted]
Re: This should never happen
#159Earlier quoted context omitted.
Of course I did. He didn't remember putting in that error condition, but he loved the story!
He doesn't remember? That's scary hah. Seems like something worth remembering. Great story, made me laugh
Do you remember all the trap code you've ever written?
Re: This should never happen
#160One 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.
Your hard disk is too small.
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!