This should never happen

Post by Someone1234 » Thu, Mar 31, 2016, 2:44 PM UTC

pbrb wrote: post #65

paulkaplan wrote: post #35

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

Hahaha, I went through the masters of comp sci program there. Those commits mentioning Borja cracked me up, and I swear "i love the smell of segfaults in the morning" was written on the wall in the big lecture room in the physical sciences building. Gives me flashbacks - that program was brutal (though really good).

Post by gue5t » Thu, Mar 31, 2016, 2:50 PM UTC

zaphar wrote: post #72

dzdt wrote: post #24

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

And this pattern is exactly why I prefer compile time type safety in my languages. This pattern is still sometimes necessary but there is a whole class of error this pattern gets used for that you can many times eliminate.

Post by zimpenfish » Thu, Mar 31, 2016, 2:56 PM UTC

Someone1234 wrote: post #111

pbrb wrote: post #65

Earlier quoted context omitted.

Hahaha, I went through the masters of comp sci program there. Those commits mentioning Borja cracked me up, and I swear "i love the smell of segfaults in the morning" was written on the wall in the big lecture room in the physical sciences building. Gives me flashbacks - that program was brutal (though really good).

Just looking at this one course and the projects... This is night and day harder than anything I had to do in my CS program. We just dicked around in Java for most of it, no C, and definitely no low level socket programming or reproducing an RFC. I mean it sounds awesome, but really hard.

Post by jdmichal » Thu, Mar 31, 2016, 3:13 PM UTC

Aaargh20318 wrote: post #84

ctdonath wrote: post #76

Earlier 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…

    enum Whatever { FOO, BAR }

    if (whatever == FOO) {
    } else if (whatever == BAR) {
    } else {
        // Should never happen!
    }

Post by yxhuvud » Thu, Mar 31, 2016, 3:16 PM UTC

stinos wrote: post #16

BinaryIdiot wrote: post #5

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

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.