|
|
|
|
|
|
by jitl
3165 days ago
|
|
|
It seems like commenters here on HN are caught on the point that GDB does provide a reasonable machine interface. That's not the author's point; responding specifically to that fact is missing the forest for one mis-labeled non-tree. Here's two paragraphs from later on that sum much better: > We've seen it hundreds of times in all kinds of software. Functions that return bool instead of an error code. Where did the precise error vanish to? Poof, it's gone! What used to be a useful error message became false, and if you're lucky you'll get a generic "Unexpected error" appearing on screen. And that's if your program is using a library. If it's calling out to a command-line worker, the most likely case is it won't get checked at all and will just get printed out into a log file you'll never find, and then never seen again. > (image) Homer's typing bird: http://www.codersnotes.com/notes/something-rotten-in-the-cor... > We're making systems that are fragile, because they're just glued on rather than bolted together. We're wrapping complex things up a wrappers that don't take the same responsibilities as the things they rely on. Like Homer's pecking bird in the Simpsons, they work just fine when everything is as expected, but when the slightest change in situation happens then everything breaks. I think the article is worth reading in full. |
|
|
However, I guess I'm not clear about the argument as a whole. The author is essentially claiming, "We write wrappers that are shoddy in that they don't consider failure cases."
That is true. What the author doesn't address is: what's the solution?
If the answer is "Code better," or "Think more," I feel like that's a straw-man.
I think the real question is how can we make a wrapper (e.g. a complex setup script) provide visibility into its problems (permissions issue, harddrive space, network issue, etc) without doubling the work involved?