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

191–200 of 214 posts

Re: This should never happen

#191

Post by chopin »

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.

In typed languages this is pretty often circumvented by choosing the wrong type. Java (even the language library) is literally littered with API's which take a String where the parameter does not have the semantics of a string (a bunch of characters with no meaning). The worst offenders take a String, support only a very limited subset and offer no explanation which are valid ones.

Re: This should never happen

#194

Post by Negitivefrags »

gerbilly wrote: post #179
brianwawok wrote: post #122

Earlier quoted context omitted.

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; T…

This reminds me of something a friend of mine did once.

He had a structure that was getting overwritten with garbage due to an overrun somewhere else in the code. Rather than debugging and trying to find out what was doing it he just put "char temp[1000];" at the top of the struct to "absorb the damage".

I believe it's still running like that in production to this day.

Re: This should never happen

#195

Post by gerbilly »

Negitivefrags wrote: post #194
gerbilly wrote: post #179

Earlier quoted context omitted.

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; T…

This reminds me of something a friend of mine did once. He had a structure that was getting overwritten with garbage due to an overrun somewhere else in the code. Rather than debugging and trying to find out what was doing it he just put "char temp[1000];" at the top of the struct to "absorb the damage". I believe it's still running like that in production to this day.

> Absorb the damage

That's funny.

The code above got written that way because at my first job, I inherited a godawful business charting API written by the lead developer.

The input to the API was a struct with 70-80 members that the caller had to fill in and there were no defaults for anything! Naturally there were not just scalars, but lots of arrays and strings in the struct, which could easily be overrun or often left null.

The users, quite understandably, didn't fill out everything, which led to frequent crashes in _my_ code because that's where the pointers would get dereferenced.

When they would see that the crash was not in their code, the users of the API would punt the error to me even though it was their bad input that caused the problem. This would happen 10-12 times a day.

I rewrote the entire thing in a paranoid style , employing the trick above and others to try and ensure that if there was bad input, that it would always crash on their side of the fence.

After I was done I got one legitimate bug report for the code, even though it was in use worldwide in our medium sized company.

Re: This should never happen

#196

Post by therealdrag0 »

georgestephanis wrote: post #99
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...

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…

That's adorable. Thanks for sharing.

Re: This should never happen

#197

Post by fit2rule »

vitd wrote: post #177
FigmentEngine wrote: post #173

Earlier quoted context omitted.

Dave Cutler?

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

I remember getting this message myself back in those days, on my brand-spanking new DEC Alpha, which shipped with a 'pre-beta' compiler to those of us who were avid recipients of DEC's first batch of Alpha workstations in anticipation of a strong porting effort to get away from the "MIPS situation" at the time .. heady days indeed!

Re: This should never happen

#198

Post by mchahn »

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 often code errors that say to contact support. I have assumed it would help get problems reported more often.

Re: This should never happen

#200

Post by wyager »

chopin wrote: post #189
wyager wrote: post #155

Earlier quoted context omitted.

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.

Sometimes you need also a user provided encoding (think of editors). In that case, the exception makes sense. Haskell or Rust would need to provide an extra API for this case. But generally you are right, stronger type checking would be preferable. Anyway, I dislike API's which take a String but only support a strongly limited subset of these. In that case, a dedicated type suits much better.

That's what typeclasses are for.
Post reply on HN