Live data from Hacker News

If you're just going to sit there doing nothing, at least do nothing correctly

devblogs.microsoft.com

51–60 of 356 posts

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#51

Earlier quoted context omitted.

Umm but you can’t find a current version of Word that actually does that. Try it sometime.

Here's a rather large (5MB) vintage 1996 Microsoft Word document: https://archive.org/download/cd-pn-0527a/CD_ROM.ISO/APPENDIX... 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.

The point made above was "opens exactly as expected". So, does it look like the authors intended in 1996? I doubt it.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#52

Earlier quoted context omitted.

Umm but you can’t find a current version of Word that actually does that. Try it sometime.

Was able to do it just fine with these government files[0,1] I found on Google. Word version 16.82 on Mac (Apple Silicon too). 0: https://www.legis.state.pa.us/cfdocs/Legis/LI/uconsCheck.cfm... . 1: https://archive.ada.gov/briefs/andersbr.doc

The point made above was "opens exactly as expected". So, does it look like the authors intended in 1996? I doubt it.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#53
post #30

Earlier quoted context omitted.

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…

To me, a better solution would be for the system to pop up a notification informing the user that printing is not supported on this platform, and then whatever other solution is OK.

> To me, a better solution would be for the system to pop up a notification informing the user that printing is not supported on this platform

That's the whole point of this article - when you can't control the various platforms that your application is run on, you want to try to do the "least bad" thing, even if that platform didn't anticipate the situation of, in this case, telling people that printing isn't supported.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#55

Your 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.

Not at all what he is saying. Microsoft has no problem testing their printer function across all platforms in their apps and removing the print button on platforms where it's not supported. Ideally, everyone would do this.

This is for other developers who are writing 3rd party apps for Microsoft's platforms and who don't always test perfectly. They may have written their app primarily for Windows and didn't consider what happens when someone installs it on their Xbox and clicks "print". In that case, the API should "just work", instead of crashing with an error message.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#56

> Well, the wrong thing to do is to have the printing functions throw a Not­Supported­Exception. The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available. When run on an Xbox, the exception will probably go unhandled, and the app will crash. Exceptions are such a catastrophically bad idea in almost all cases. It is absolutely infuriatin…

> if it can throw and,

noexcept.

Granted, it may not have the annotation but still not throw in reality, but a Rust function can also declare a Result return type but never actually return an error.

> if it can, not know what it can throw

How do you square that with backward compatibility?

If you declare what you can throw, what do you or any of your transitive dependencies do when they want to change their implementation in a way that makes a new error a possibility? Either you shove it all into an UNKNOWN error that you hopefully declared from the get go to be future-proof, or you break all your downstream users every time. So either no compatibility, or over time your API converges to a meaningless UNKNOWN error code for almost everything and a bunch of legacy error codes that are never used.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#57

Earlier quoted context omitted.

Here's a rather large (5MB) vintage 1996 Microsoft Word document: https://archive.org/download/cd-pn-0527a/CD_ROM.ISO/APPENDIX... 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.

The point made above was "opens exactly as expected" . So, does it look like the authors intended in 1996? I doubt it.

If you "doubt" it, please provide a specific example of what you believe is inaccurate in the document rendering.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#58
post #10

People 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.

A file that was written in Word '97 did not even open exactly as expected on two different computers 25 years ago. Formatting depended on the installed printer drivers. Good luck with that document today. My LaTeX files from 35 years ago, on the other hand - they just do fine.

>My LaTeX files from 35 years ago, on the other hand - they just do fine.

Yeah, because they're plain text. A fairer comparison would be whether they render pixel perfectly as 35 years ago, which I doubt.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#59
post #4

"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

Perhaps you missed the context in which it was made clear that this imperfect solution was still less bad than all other options.

It seems the point resembled: 'this device doesn't support printing, don't return obscure, unhelpful or crashing errors; return something that makes sense so that the user can figure out and move on'. I.e.: Fail gracefully.

Re: If you're just going to sit there doing nothing, at least do nothing correctly

#60
post #10

People 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.

A file from 1997? Maybe if you get lucky, but there's also a good chance that it will simply look wrong in any office application you try. With Word you can't even guarantee that reopening the file on the same computer & version won't change its formatting. That was the reason I learned TeX.

And games? Microsoft broke numerous games by shutting down GFWL. I had to pirate Dark Souls as my original copy wasn't playable until it got re-released on Steam.

Post reply on HN