Live data from Hacker News

This should never happen

github.com

71–80 of 214 posts

Re: This should never happen

#71

Earlier quoted context omitted.

This is amazing.

amazing waste of time that is, of everybody, the commit authors and the people spending time looking them up and making slides out of them. And lets not forget the waste of space on HN regarding this referral post.

I bet you're a blast at parties

Re: This should never happen

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

Re: This should never happen

#73

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

Shoutout to borja

Re: This should never happen

#76
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…

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

Re: This should never happen

#77

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

Why man has nipples if he does not breast feed?

Re: This should never happen

#78

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

Yep. There's What A Terrible Failure exception in the Android codebase (i.e. "throw wtf"). http://developer.android.com/reference/android/util/Log.html...

My code made the Android OS throw this once. Not a terribly useful error to resolve.

Edit: My mistake. I misremembered. It's a logging function. I should have actually read the link I provided.

Re: This should never happen

#80
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…

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

Except that you never know how the code you wrote in a module will be used by other developers in the future. Such defensive programming will a least help others prevent mistakes when using your code.
Post reply on HN