Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

111–120 of 356 posts

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

#111

Post by Aaargh20318 »

Scarblac wrote: post #36
happytoexplain wrote: post #23

The 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 Not­Supported­Exception." No, no, absolutely no - what the author is describing is a hack to support a shitty client. Yes, you have to do this sometim…

No, not a shitty client, just one that was written before you decided to make this change. If your API breaks it while it doesn't change, it's the API that's being shitty, not the client.

> No, not a shitty client, just one that was written before you decided to make this change.

Has the Xbox ever supported printing? Why even have these APIs? Just don’t offer them at all in the Xbox SDK. You shouldn’t be able to compile code that tries to call these when targeting Xbox.

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

#112

Post by derefr »

codexb wrote: post #101
Scarblac wrote: post #36

Earlier quoted context omitted.

No, not a shitty client, just one that was written before you decided to make this change. If your API breaks it while it doesn't change, it's the API that's being shitty, not the client.

It depends. Did the API document that it could raise an exception if printing isn't supported? Is that unhandled in the client? Then yes, it's a shitty client. If you're talking about making backwards-incompatible breaking changes to an API, that's another thing.

In the context of the article, no, the existing API never threw (or was documented as capable of throwing) NotSupportedException.

The article:

> The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available.

I.e. there is no concept in the (desktop) Windows printing subsystem of printing as a feature not being available; on desktop Windows, printing as a feature is available by definition.

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

#113

Post by ploxiln »

gruez wrote: post #102
maerF0x0 wrote: post #91

I've learned this as "swallowing errors" and IMO it's a poor practice. Not only does it not solve the issue at hand (you cannot print on an xbox), but it actively hides how broken the software is, which makes bug discovery and testing much harder. This is one thing I like about Go's panic. You're mostly not supposed to use it or recover from it at run time. It serves as a great vehicle to blare loud sirens at testing…

>It serves as a great vehicle to blare loud sirens at testing time that you (the programmer) screwed up (and that's ok, we all do), and it's time to figure out where and how to fix it :) Right, but if you read the article, the author is talking less about the developer experience and more about the user experience. "blare loud sirens" is great if you're a tester/developer, not so much if you're an end user. When it c…

If you read the article, this isn't swallowing errors, it's just returning more-backwards-compatible errors.

> ...when the app tries to print, it will ask the user to select a printer, and show an empty list. The user realizes, “Oh, there are no printers,” and cancels the printing request.

> To deal with apps that get fancy and say “Oh, you have no printers installed, let me help you install one,” the function for installing a printer can return immediately with a result code that means “The user cancelled the operation.”

> a documented return value is ERROR_CANCELLED to mean that the user cancelled the creation of the widget. Therefore, apps are already dealing with the possibility of widgets not being created due to conditions outside their control, so we can take advantage of that

I'm annoyed when "modern web apps" (or similar desktop apps) seemingly do nothing when there's some error, you don't know if you need to wait a bit, or click again (great fun when the UI jumps 1ms before your re-click), or full reload/restart ... luckily that's not at all what this article recommends!

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

#114

Post by xp84 »

bitwize wrote: post #75
happytoexplain wrote: post #23

The 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 Not­Supported­Exception." No, no, absolutely no - what the author is describing is a hack to support a shitty client. Yes, you have to do this sometim…

> No, no, absolutely no - what the author is describing is a hack to support a shitty client. If you were on the Windows team and I was your manager, I might fire you for that. This is Windows. You do not break applications that users depend on. Ever, ever, ever. If you have a "shitty" or misbehaving client application, you use whatever workarounds, shims, and compatibility hacks it takes to make the application work…

I really appreciate this approach. It actually takes, in my humble opinion, much more discipline (and requires checking ego at the door) to implement this idea, compared to the “my code just throws exceptions or a 400 Bad Request anytime you aren’t following the most recent revision of our API” mindset. I work on Web apps which are much closer to that second approach usually, but if I were working on a platform (NT) which was 30 years old and will live another 30 years in all likelihood, you 100% have to take the approaches Raymond Chen is explaining.

“We’ve decided software that operates your 100 ten-million-dollar-each CNC machines is ‘shitty,’ so buy new equipment so you can get Windows 11” isn’t going to fly, it would get the whole company laughed out of the room.

Especially because what is allegedly making them shitty would just be someone’s failure to predict some minor detail about the future of the platform. APIs do have to change, and the creative part is thinking of how they can be safely rendered inoperable without damaging anything that didn’t predict that removal. Sure, you can’t print, but that’s in this example a deliberate design decision of the platform, probably for good reasons.

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

#115

Post by PaulHoule »

mey wrote: post #108
maerF0x0 wrote: post #91

I've learned this as "swallowing errors" and IMO it's a poor practice. Not only does it not solve the issue at hand (you cannot print on an xbox), but it actively hides how broken the software is, which makes bug discovery and testing much harder. This is one thing I like about Go's panic. You're mostly not supposed to use it or recover from it at run time. It serves as a great vehicle to blare loud sirens at testing…

Error design depends on context. For most of the systems I work on, fail fast on request for anything out of spec is the correct design. B2B/Microservices/API focused systems. Windows however has focused on bending over backwards to provide compatibility (including memory patching popular software that was broken, like Simcity https://arstechnica.com/gadgets/2022/10/windows-95-went-the-... ). In the context of a user…

It's hard to overstate how hard Microsoft has worked to maintain backwards compatibility.

Recently I had to read an old Access file and where I work we still keep Office '97 around for this purpose and it is quite amazing that it installs and works just fine on Win 11, Clippy works just fine, in fact all the other lame-ass things Office '97 does to take over your desktop all still work even if they don't quite visually match the current desktop.

The thing is that Microsoft has a framework built into Windows where they can specify different system behaviors such as that Simcity case where the game didn't work with a new memory allocator so they put in a flag so an application that needs it can get the old memory allocator. They have a very systematic approach to the half-baked and haphazard process of patching the OS so you don't have to patch applications.

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

#116

Post by apetresc »

gruez wrote: post #66
alpaca128 wrote: post #60

Earlier quoted context omitted.

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…

>With Word you can't even guarantee that reopening the file on the same computer & version won't change its formatting. Source? This seems utterly bizarre.

Before the new '.docx`, '.xslx', etc. formats, when it was still just .doc, .xsl, etc., the document format was (as I've heard it told) essentially just a memory dump of Word/Excel's state for that document at the time you saved. And since it's easy to imagine that serializing/deserializing such a complex thing might not be always 100% perfectly idempotent, it would indeed happen that just the act of opening a file would change it in some subtle way.

That hasn't been the case in a long time, though.

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

#117

Post by MichaelZuo »

EvanAnderson wrote: post #105
weinzierl wrote: post #51

Earlier quoted context omitted.

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

Just flipping thru it I'm not seeing obvious issues. In terms of being usable for reference I think it's reasonable. The diagrams and tables look intelligible and not garbled. Layout isn't visible screwed-up. Will it be a 1-to-1 with printed output from 1996? Probably not.

“exactly as expected” is a much higher bar to clear then roughly as expected.

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

#118

Post by greatgib »

maerF0x0 wrote: post #91

I've learned this as "swallowing errors" and IMO it's a poor practice. Not only does it not solve the issue at hand (you cannot print on an xbox), but it actively hides how broken the software is, which makes bug discovery and testing much harder. This is one thing I like about Go's panic. You're mostly not supposed to use it or recover from it at run time. It serves as a great vehicle to blare loud sirens at testing…

This is the Microsoft way to do things, this is why their products like Windows are so crappy, full of bugs, unexpected behaviors and a big dump of shit of legacy behaviors expected on top of a lot other legacy behaviors on top of another 1989 legacy behavior that every forgot.

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

#120

Post by amelius »

gruez wrote: post #102
maerF0x0 wrote: post #91

I've learned this as "swallowing errors" and IMO it's a poor practice. Not only does it not solve the issue at hand (you cannot print on an xbox), but it actively hides how broken the software is, which makes bug discovery and testing much harder. This is one thing I like about Go's panic. You're mostly not supposed to use it or recover from it at run time. It serves as a great vehicle to blare loud sirens at testing…

>It serves as a great vehicle to blare loud sirens at testing time that you (the programmer) screwed up (and that's ok, we all do), and it's time to figure out where and how to fix it :) Right, but if you read the article, the author is talking less about the developer experience and more about the user experience. "blare loud sirens" is great if you're a tester/developer, not so much if you're an end user. When it c…

Maybe then raise an assertion error, which only has an effect in development mode.
Post reply on HN