I 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 resonates with me. My computers used to crash at the app level, OS level or hardware level. Now when something goes wrong the system just kinda gets lazy and stops working. But it won’t crash. I’ve had my mac pinwheel on the login screen. I can still access the shell and file shares remotely, and even screen share to a logged in user. But login.app refuses to crash so it’ll just pinwheel. I’m glad I never forgot…
If you're just going to sit there doing nothing, at least do nothing correctly
31–40 of 356 posts
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#32Why /wouldn't/ I want to print something from my Xbox?
You might be viewing something and want to print it, but that's clearly not desirable enough for Microsoft to build print functionality into the Xbox UI.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#33"The idea here is to have the printing functions all behave in a manner perfectly consistent with printing being fully supported, yet mysteriously there is never a printer to print to." This must be satire. Otherwise I can't comprehend how something as infuriating as this could be presented as a good or smart thing to do UX-wise
Just because an XBox can't print doesn't mean that an app that prints shouldn't run on XBox. It should just mean that the printing function shouldn't run. How to achieve that is exactly what Raymond Chen, a Microsoft and Windows veteran, is trying to explain here.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#34The 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…
It all depends on how the clients are currently using the API. If the clients are already testing for NotSupportedException, then that's what you should return. But if not, you need a different approach.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#35Re: If you're just going to sit there doing nothing, at least do nothing correctly
#36The 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
#37I 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…
functions that return correct null responses isn't the ideal behaviour, it's the fallback for when you're already off the happy path.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#38People 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.
My LaTeX files from 35 years ago, on the other hand - they just do fine.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#39People 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.
That file opens and appears to render just fine for me in Word 2016.
This has been my experience w/ Office files in general. Old files open and render very well in newer versions.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#40Earlier quoted context omitted.
Except now you have lost the ability to run all the software that cannot be fixed and recompiled for whatever reason.
You could still offer the mocked APIs, but have them be opt-in. Also, having the compiler throw an error doesn't mean that an older, already compiled executable won't work.
And when the older, already compiled executable calls the API, how do you make things "work"? That's exactly what the article is about.