If you're just going to sit there doing nothing, at least do nothing correctly
41–50 of 356 posts
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#42I understand the logic here, and I'm aware Microsoft has a large number of convoluted backward-compatibility requirements, but this seems like drinking to solve your problems and just putting off the inevitable hangover. To be clear: what you're doing here is lying to the user and the developer. Maybe that's justified in isolation, but now this lie is one more bit of "hidden state" you have to keep track of in furthe…
This is not weird "hidden state" on the implementer's side. It's a straightforward dummy API and all you need to do to test it are a few straightforward asserts that it returns the correct dummy values and doesn't crash.
> I have a feeling that "solutions" like this are part of why an increasing number of my computing problems take the form of, "I tried to take an action, nothing happened. No error, no activity, nothing.", and are impossible to debug or diagnose.
That's precisely not what this is. The whole point of the article is to do nothing correctly. Presenting an empty list of printers is consistent with a PC that simply doesn't have any printers installed. A wrong thing to do would be, for example, presenting a dummy printer that accepts jobs but of course never prints anything.
You don't break the users of your API, period. That shouldn't be controversial. Unfortunately, too many people seem to think they need to do everything over every couple of years only to produce a solution that is no more extensible and resistant to bitrot than the one they're replacing.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#43People are reacting negatively as expected, but stuff like this is exactly why you can click on a file that was written in Word '97 or a game that was compiled for MS-DOS three decades ago and it opens on your computer exactly as expected. Backwards compatibility is always messy. You either do it imperfectly or don't do it at all.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#44People are reacting negatively as expected, but stuff like this is exactly why you can click on a file that was written in Word '97 or a game that was compiled for MS-DOS three decades ago and it opens on your computer exactly as expected. Backwards compatibility is always messy. You either do it imperfectly or don't do it at all.
Umm but you can’t find a current version of Word that actually does that. Try it sometime.
0: https://www.legis.state.pa.us/cfdocs/Legis/LI/uconsCheck.cfm....
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#45I find nothing quite as frustrating as UIs that suggest a device could exist, but it's not there right now. I then have to spend time to discover that these devices are not supported, and that screen was just some mock someone came up with.
Sure, but you'd be more frustrated if your app just crashed. If the app is not prepared for printing not being supported, and printing just throws an exception, the app probably just crashes. That's bad. If the app is prepared for printing not being supported, it should be calling the explicit API to check if printing is supported, and then not displaying the UI for printing if it isn't. The article is not about thes…
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#46It's a crap analogy. Why would you expose a printing API on a device without printing support? Just ifdef it out on the build.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#47The specific thing the author is suggesting is correct (components should suffer before users do), but I take great offense to their framing. "There may be times where you need to make an API do nothing." "The wrong thing to do is to have the printing functions throw a NotSupportedException." No, no, absolutely no - what the author is describing is a hack to support a shitty client. Yes, you have to do this sometim…
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#48The specific thing the author is suggesting is correct (components should suffer before users do), but I take great offense to their framing. "There may be times where you need to make an API do nothing." "The wrong thing to do is to have the printing functions throw a NotSupportedException." No, no, absolutely no - what the author is describing is a hack to support a shitty client. Yes, you have to do this sometim…
Raymond is behind arguably the foremost exemplar of this (Windows) but the same thing happens in the Linux kernel ABI, glibc, the web platform, Java, and so on.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#49Your ecosystem has gone so complex that you can't test it anymore. So instead of handling errors properly you suggest to implement a convoluted user flow that offers always failing actions (install a printer when there's none available). If that's really the suggestion of product and engineering leadership at MSFT no wonder all their products...err...work as designed.
When the software your customers are relying on breaks because of a change you made, it doesn't matter whose "fault" it is. It's broken, it broke because of something you did, and you have burned customer trust - not the trust of whoever wrote the software you believe is "wrong" or "to blame", trust of your platform and company.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#50Your ecosystem has gone so complex that you can't test it anymore. So instead of handling errors properly you suggest to implement a convoluted user flow that offers always failing actions (install a printer when there's none available). If that's really the suggestion of product and engineering leadership at MSFT no wonder all their products...err...work as designed.
An operating system with billion+ install base, and millions of developers tends to be complex. I'm not sure what you're proposing here, have your platform/software be more niche? Somehow get all of them to fall in line?
>So instead of handling errors properly you suggest to implement a convoluted user flow that offers always failing actions (install a printer when there's none available).
How are you going to "handle errors properly" if the publisher of the software in question went out of business?