[existencebox]

I think it's situationally useful. If I take the author of the OP code at their word, this is one of those situations.

Core, critical plumbing/logic at the kernel of business critical, long-lived applications, will be the source of my stress-dreams long into the twilight years of my life; in the form of a lack of documentation and a presence of organic growth.

To criticize myself quite bluntly: If the core code I worked on at work looked like this, I'd feel a great deal more comfortable in some of the changes/digging that inevitably arises.

I would never use it as an absolute metric; but I'd use the level of comfort e.g. a new dev feels when looking at something that might otherwise be a spiderweb and saying "Oh this makes sense" (As I do when looking at OP) as a north star for the most sensitive bits of logic.

[thockingoog]

As one of the authors of the original code here, this was the result of several days of intense works by a half dozen people working through every corner case we could dream up, and a bunch we thought of on the spot.

It is in no way a guarantee that we got them all, but after spending so much time reason in through why those 'else' clauses were correctly empty, we thought it would be rude not to write it down.

In truth it was as much for future-me as anyone. My memory is know. To be spotty. :)

[boulos]

Tim, does someone have a fuzzer running against this? Or even some static analysis ensuring that say the enums from various things are actually handled?

[thockingoog]

Probably not, in truth. It's a great idea and not just for this code, but lots of tricky stuff.

[sleepybrett]

As a user of this particular code, and someone who found several bugs in it in the early kubernetes days that were very hard to trace. I applaud the hell out of this.

[galangalalgol]

Why isn't the core code not most of the code? Why isn't it all core code with a tiny dash of ux or data access sprinkled on it? With, maybe, one abstraction layer somewhere (but never two touching!l.