Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This should never happen

github.com

Post reply on HN
Print view View original

171–180 of 214 posts

Re: This should never happen

#171

Post by amenod »

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…

I often use such error checking. Usually the value of such error message is in making the code easier to reason about, to further clarify some obscure use case (which can't happen). And if it does happen anyway - well, at least we get that alert. ;)

Re: This should never happen

#172

Post by frostymarvelous »

ctdonath wrote: post #76
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…

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

Brilliant response.

Re: This should never happen

#173

Post by FigmentEngine »

vitd wrote: post #169
FiatLuxDave wrote: post #94

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

I saw one like this once. Back in the early 90s I was working at a computer lab at my university. We had just gotten in a 300MHz DEC alpha, and that thing was a screamer! It was so fast that X-windows didn't feel slow on it! (And this was in the day of 25-50Mhz 386s and 486s.) I was compiling some tiny test program on it, and it spit out an error message that said something to the extent of "This shouldn't happen. Em…

Dave Cutler?

Re: This should never happen

#174

Post by semi-extrinsic »

pron wrote: post #121
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).

> is not inclined to prove it (as represented by coding type checking or other handling) This is known as a reachability problem that in the general case cannot be proven . So, "not inclined" may actually mean "can't (in any reasonable amount of time)".

It's not "in any reasonable amount of time". Proving in the general case whether a variable is unused in code or not is equivalent to solving the halting problem. This follows from Rice's theorem:

https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by_redu...

Re: This should never happen

#175

Post by pron »

semi-extrinsic wrote: post #174
pron wrote: post #121

Earlier quoted context omitted.

> is not inclined to prove it (as represented by coding type checking or other handling) This is known as a reachability problem that in the general case cannot be proven . So, "not inclined" may actually mean "can't (in any reasonable amount of time)".

It's not "in any reasonable amount of time". Proving in the general case whether a variable is unused in code or not is equivalent to solving the halting problem. This follows from Rice's theorem: https://en.wikipedia.org/wiki/Rice%27s_theorem#Proof_by_redu...

Yes, but it's more nuanced than that. Even if you can prove that a computation always terminates you can't necessarily prove that it yields the wanted result in any reasonable amount of time. This is the bounded halting problem, and it applies even to languages that only allow terminating computations. In those languages, the halting problem is nominally gone, but the bounded halting problem is just as bad as for Turing-complete languages. Just how bad is it? It is a time complexity class that includes all time complexity classes, i.e. it is harder (in general) than any problem that is computable and known to complete within f(n) steps, where n is the size of the input and f is any computable function.

Re: This should never happen

#176

Post by amagumori »

alttab wrote: post #166
sliverstorm wrote: post #159

Earlier quoted context omitted.

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

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

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

Re: This should never happen

#177

Post by vitd »

FigmentEngine wrote: post #173
vitd wrote: post #169

Earlier quoted context omitted.

I saw one like this once. Back in the early 90s I was working at a computer lab at my university. We had just gotten in a 300MHz DEC alpha, and that thing was a screamer! It was so fast that X-windows didn't feel slow on it! (And this was in the day of 25-50Mhz 386s and 486s.) I was compiling some tiny test program on it, and it spit out an error message that said something to the extent of "This shouldn't happen. Em…

Dave Cutler?

Could be. I never got to find out because, as I said, I sent it off to our IT department.

Re: This should never happen

#178

Post by rcarmo »

cname wrote: post #125
rcarmo wrote: post #86

Earlier quoted context omitted.

I preserved for posterity a colleague's unique commit style: https://gist.github.com/rcarmo/c671555169abbae83a1a

In case anyone looks at that and thinks it's cute or clever or fun... it's not. People will end up hating you for doing that. Okay, maybe hate is too strong, but it will certainly engender some strong negative feelings in anyone who has to try to figure out what you did (and when and why you did it).

To his credit, these were usually on his/dev branch, and there were copious comments and docs.

On the other hand, a lot of this was on a large PHP codebase, so the result soon became the stuff of legend :)

Re: This should never happen

#179

Post by gerbilly »

brianwawok wrote: post #122
z3t4 wrote: post #106

Earlier quoted context omitted.

It's a good idea to haw a check for memory corruptions at regular intervals to keep your sanity.

How do you do that? I get on bootup you could do a little diddy, but how would you know if random bits are getting flipped? Seems tricky for an embedded device...

Not quite for memory _corruption_ but back when I was writing API code in C, I would place 'sentinels' at each end of my structs.

  struct somestruct {
    int s1;
    int data;
    char * moreData;
    int s2;
  }
When the caller of the API needed to call my code, it had to first call a function to get an instance of the struct. This constructor like code would allocate the memory for the struct, and then set s1 and s2 to 0xDEADBEEF;

The user would then fill out the rest of the struct and pass it back in as an argument to another call.

If either s1 or s2 wasn't 0xDEADBEEF, I would throw an error to the caller.

I helped me catch a lot of cases where the caller to the API had overrun some string while filling out the inputs.

Re: This should never happen

#180

Post by eternalban »

ctdonath wrote: post #76
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…

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 a sub-pattern of "ain't got time for dat".

Disagree on this. It has nothing to do with efficiency in context of unlikely events. As others have noted here, it is effectively an assertion of expected language/system/operating-environment properties. Think axioms.

Post reply on HN