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

https://devblogs.microsoft.com/oldnewthing/20240216-00/?p=109409

by AndrewDucker • 2 years ago

432 347 2 years ago

devblogs.microsoft.com

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

kentonv6• 2 years ago

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 these apps, it's about what to do about apps that fail to check first.

The bug is with the app, but a good platform does its best to make bad apps work anyway, rather than have them just crash.

tsimionescu7• 2 years ago

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.

nerdponx• 2 years ago

Sure, but you'd be more frustrated if your app just crashed.

I don't know about that. If it crashes, I might not try that thing again.

yungporko2• 2 years ago

these aren't the only two options.

first of all, i certainly wouldn't be more frustrated if the app just crashed, but how about just letting the user know that the xbox can't print? why does everybody seem to think that's out of the question?

nonethewiser7• 2 years ago

Perhaps the software author is to blame here then not Microsoft. Because they didnt handle the printer case. Where Microsoft comes in is that the software doesnt crash because the software provider didnt account for printers.

Analemma_2• 2 years ago

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 further development and integration testing. And just like in the real world, lies have a tendency to compound on themselves until you're completely lost in them and have no idea what reality is.

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. UX designers made themselves terrified of ever showing an error code to a user, but they took that and replaced it with a world where your shit just doesn't work, and when you try to figure out why, all the OS does is shrug.

ace2358• 2 years ago

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 to turn things off and on for troubleshooting :(

Analemma_2• 2 years ago

I have a suspicion that "number of crashes" got badly Goodharted inside major OS vendors. After all, you can "prevent" most crashes by just having a top-level "catch(Exception e) {}" handler, which of course just leads to the program doing nothing instead in an un-debuggable way, but hey: crashes went down! KPI achieved!

bombcar3• 2 years ago

My experience is that macOS especially really REALLY absolutely hates when the Internet goes sideways - not actually down, but really bad packet loss; DNS starts being slow and failing sometimes but not completely ... then you enter hell.

Next time it happens try turning network connections all the way off.

acheron• 2 years ago

To be fair, sometimes you get "Oops, an error occurred, LOL!"

FreeFull2• 2 years ago

As far as alternatives to what the article suggested go, I think the ideal solution would be to have a compile-time error, so the developers never even get as far as having their printing code try to run on the Xbox. And since it's a compile-time error, there doesn't need to be any kind of runtime error handling or cost either.

paxys2• 2 years ago

Except now you have lost the ability to run all the software that cannot be fixed and recompiled for whatever reason.

Arainach22• 2 years ago

Apps aren't being compiled here. Apps already exist and new platforms and platform functionalities are being made available.

Launching platforms is an eternal chicken and egg problem: You want to launch a new platform. Users want apps before they buy into the platform. Developers want users and a guarantee they will spend money before investing time and money building apps for the platform. If you're really really rich, you can literally pay developers to write apps for you, but ask Microsoft how that went with Windows Phone.

Instead, the most reliable way (I said most reliable, not reliable) is to leverage an existing group of apps onto your platform. Maybe you have a phone ecosystem and want to get into tablets. So you take the already existing phone apps in your store and let them run on your new platform.

There is no recompiling. There is no build.

There is no "build" because the source code was lost when all of the company's assets were sold off in 2002.

There is no "build" because the developer made a game, put it on your app store, moved on to the next game and has no interest in supporting this game that isn't providing any significant new revenue.

There is no "build" because this is FooManager 6.0, the company that makes FooManger wants everyone to buy FooManager 7.0 and isn't making any further changes to 6.0.

etc. etc. etc.

Binary compatibility is what matters. Nothing else is of particular significance.

In addition, if recompiling an app for your new platform yields compile errors and requires work (as opposed to targeting a new platform version in a manifest and just hitting build), developers on your platform are significantly less likely to spend the time to do so.

notatoad• 2 years ago

as the article says, the correct solution is to provide an API that applications can access to check if the functionality is offered at all.

functions that return correct null responses isn't the ideal behaviour, it's the fallback for when you're already off the happy path.

crabmusket• 2 years ago

I think there's a difference between an API that can be used to check if functionality is available, and an API that must be used before that functionality is offered to the application. E.g.

    CheckForPrinting : () -> Maybe PrintToken
    ShowPrintDialog : PrintToken -> Dialog

mike_hock2• 2 years ago

So what's your solution then? Break all apps simultaneously that do not have extensive tests for gracefully handling cases that were impossible when they were created?

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.

chrisjj18• 2 years ago

So what's your solution then? Break all apps simultaneously that do not have extensive tests

No test required. Just try... catch.

for gracefully handling cases that were impossible when they were created?

You can never know they are impossible. That is why you have a top-level try...catch.

Jabrov2• 2 years ago

"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

recursive2• 2 years ago

The alternative is that the app fails to run at all. Doesn't seem like satire to me.

GMoromisato2• 2 years ago

Or worse, crashes at a random spot because it tried to initialize the printer stack.

kentonv6• 2 years ago

No, this is a guy who has been one of the architects of Windows for more than 30 years giving you hints about how they achieved their reputation for amazing backwards compatibility. He really, really knows what he's talking about.

avery17• 2 years ago

What do you suggest as an alternative?

daveoc642• 2 years ago

If the two options are "this app can't run on your Xbox" or "this app runs on your Xbox, but the printing functions don't work and some of the messages are a little weird", which option do you think users would prefer?

chrisjj18• 2 years ago

But the first option is not "this app can't run on your Xbox". It is "This app possibly cannot run after trying to print".

elevatedastalt2• 2 years ago

No it's not satire. It's a demonstration of the excellence in backward compatibility and cross-compatibility that Microsoft has always been known for, and that so-called modern players like Google and Apple don't take seriously.

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.

toss12• 2 years ago

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.

Contortion2• 2 years ago

I wouldn't call creating mystery failing gracefully. As a user I would prefer a full crash to the application gas lighting me by suggesting there's something wrong with my setup (we can't find your printer vs you're not allowed to print).

If anything creating mystery about what the app is doing is the direct opposite of good UX.

chrisjj18• 2 years ago

I.e.: Fail gracefully.

There's no grace in misleading the user and wasting his time.

alpaca1284• 2 years ago

MS being okay with the user clicking somewhere and never getting any reaction out of it explains many of my interactions with Windows 10.

bastawhiz• 2 years ago

So what, you crash the app? What if there's no API to say "there's no printing on this device"? What is the difference between a device where printing isn't supported and a device where a printer isn't set up yet? Showing an empty list of printers isn't a bad solution, frankly.

Jabrov2• 2 years ago

Ahh I completely misunderstood the article from a quick reading. It seems like the only solution to a tricky problem.

Thanks to anyone who replied to me pointing that out. It's a good example of when one should read the article more closely before commenting!

lucianbr5• 2 years ago

Once upon a time it was considered a great strategy for browsers to make the best effort to display a page, even if the html code had errors. Just try to guess the author's intention as well as you can, and go ahead. Errors are bad. Users don't want errors.

I thought we learned from that experience. Apparently not.

debacle• 2 years ago

"We" did. Microsoft didn't. Not unexpected.

recursive2• 2 years ago

Is this part of a fan fiction where MS isn't amazing at legacy compatibility?

subarctic• 2 years ago

What did you think we learned?

lucianbr5• 2 years ago

That every single behavior that attempts to guess the users's intent becomes a relied upon part of the software, and this over time grows to an impossible amount of cruft.

See this, hilariously hosted also by microsoft: https://techcommunity.microsoft.com/t5/discussions/funny-sto...

And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to be Safari. And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and all browsers pretended to be Mozilla, and Chrome called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13, and the user agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded.

kentonv6• 2 years ago

Browsers still follow that strategy. The effort to replace it with strict validation (XHTML) failed. What succeeded instead was HTML5, which went back and explicitly defined how every possible invalid sequence should be interpreted, so that browsers would at least be consistent about it.

imperfectsoft• 2 years ago

the evolution we have seen in software in the last 20 years isn't great except for LLMs, but then again, they messed them up with censorship.

I would not miss much if I was time-traveled to 1999.

wvenable3• 2 years ago

Browsers being permissive with what they accept is what made the modern web possible.

If early browsers displayed an error the first time it came across an <img> tag, instead of just best-effort rendering the page, then every new browser feature would have been smothered in the cradle.

_gabe_• 2 years ago

Go type in:

  <p>Hello
  <br></br>
  World!

And see the errors that now show up because of the wisdom we gained… wait, it still renders alright? I guess we still have much to learn then. Or, there might be something to gracefully handling certain classes of errors while crashing on exceptional cases.

pests• 2 years ago

Not sure if you meant to use <p> as an example because it's well-defined as an optional closing tag.

This is a completely normal usage and some people even author their HTML like this. Granted this is part of the effort to standardize error handling.

That unclosed <p> will auto-close as soon as you start another paragraph or close it's parent element. Likewise this is how I do lists these days:

  <ul>
    <li> One
    <li> Two
  </ul>

The subsequent li's will close the previous and the bounding ul ends the last list item.

fidrelity• 2 years ago

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.

Arainach22• 2 years ago

What is "your ecosystem" here? Part of running a platform is that the code running on it is written by other people, not you, and that your customers will be relying on that code.

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.

xp846• 2 years ago

It is so obvious from reading these comments here who is not, and would never ever want to be, a platform engineer. It’s hard for some people to grasp that you need to not only interact with, but thoroughly accommodate, software written by others whom you don’t control (often due to the one-way direction of time flow).

gruez8• 2 years ago

Your ecosystem has gone so complex that you can't test it anymore.

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?

nearbuy2• 2 years ago

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.

anonms748473• 2 years ago

From my experience in other MS orgs, this was the prevailing approach. There are masses of bandaids on top of systems that have organically evolved over decades. Leadership is generally promoted from within so have a blind spot to how organisation incentives lead to these technical outcomes.

throwawayfrsbob• 2 years ago

And they ask why we're cynical. I'm about done with this whole "personal computing" fad.

paxys2• 2 years ago

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.

dupertrooper• 2 years ago

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

EvanAnderson2• 2 years ago

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.

judge2020• 2 years ago

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

weinzierl5• 2 years ago

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.

gruez8• 2 years ago

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.

wrs• 2 years ago

If I recall correctly, the common phenomenon where you open a Word document, immediately close it, and are asked whether you want to save your changes (???) has something to do with printer settings.

wewtyflakes• 2 years ago

I hear that refrain often regarding Microsoft, but with games, I have not had good luck. I resort to using GOG, which itself ends up virtualizing the environment anyway. For example, I do not think anyone would have success installing the original Sim City on Windows 11.

awkwardpotato• 2 years ago

Fallout 3 was unplayable (without mods/patches) on Windows 10 for many years because of its dependency on "Games for Windows Live" from Windows 7

benjaminpv3• 2 years ago

Yeah, people frequently trot out the Sim City classic example, but the fact is that games in particular have borne the brunt of Windows API changes. If it didn't happen we'd have no need for wrappers like dgVoodoo: software once only meant to wrap Glide calls, but now used to get around deprecation to DirectX as well. Not to mention the breaking changes to the audio stack that happened between 9x and Vista.

alpaca1284• 2 years ago

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.

gruez8• 2 years ago

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.

mnw21cam5• 2 years ago

I had the same with OpenOffice (before LibreOffice was a thing). I created a nice document while logged in remotely to a Linux computer over Xvnc. When I opened it on the native terminal, the layout was different. Same computer, same version of OpenOffice, different X server.

bakugo• 2 years ago

I assume the negative reactions are due to the large Apple user base on HN. Most of these people are likely so used to being told "this software was built for a version of your OS released 2 years ago so you can't use it anymore, tough shit", they've come to expect it.

pas2• 2 years ago

nah, it's because all of this is just lip service. windows11 is getting worse and worse.

and cool that Mr Chen thinks about UX and compatibility, but MS as whole does not really. important business apps got special treatment, and that's it. (MS and its corporate entourage solved this mostly by providing Windows and "security" patches for it, for a lot of money.)

spiderice• 2 years ago

You just created a scenario in your head that confirmed an existing bias in your head and then assumed that your made up scenario matched reality. Very weird to read.

blibble• 2 years ago

MS-DOS software doesn't work on modern 64-bit windows

you get a dialog saying "unsupported"

now you can download dosbox but that isn't really "exactly as expected"

Waterluvian• 2 years ago

I wish this was actually truthful. I’ve had a gigantic headache getting every childhood game I kept working. In almost every case I gave up or re-bought from GOG, basically paying for the work done to sort out compatibility.

saghm• 2 years ago

I think the reason this is getting a negative reaction is because he doesn't really clearly state the problem he's actually trying to solve until the end (and describes it as "bonus chatter" when it's actually just a much better explanation than he gives at the top of the article).

To clear up some confusion: The idea here is that the printing API has always existed on desktop, where printing is supported, and the “get me the list of printers” function is documented not to throw an exception. If you want to port the printing API to Xbox, how do you do it in a way that allows existing desktop apps to continue to run on Xbox? The inert behavior is completely truthful: There are no printers on an Xbox. Nobody expects the answer to the question, “How many printers are there?” to be “How dare you ask me such a thing!”

If he just used the words "existing desktop apps" in the second paragraph of the article instead of the second to last, I don't think people would be reacting so negatively. Instead, when he talks about avoiding "gaslighting" by returning an invalid pointer by just gaslighting in a different way by lying about the error that occurred, it almost sounds unhinged.

hailmac• 2 years ago

Why /wouldn't/ I want to print something from my Xbox?

daveoc642• 2 years ago

Due to the input device most people will use (controller), apps that work best on Xbox are those used to consume content like photos or videos.

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.

maerF0x03• 2 years ago

I mean, it has USB ports. If I can plug it in, I'd like to be able to use it _somehow_ , even if that means installing another app that does direct port/device access or w/e . ie, it should be possible (but not necessarily super easy)

Arainach22• 2 years ago

The printer drivers don't run on XBox. XBox isn't exposing all of the legacy Win32 APIs and driver models available in desktop.

mrguyorama• 2 years ago

It's an x64 CPU running most of Windows with plentiful and fully supported USB ports. Why CAN'T I print from my Xbox? I can print with my phone, so why not my Xbox?

I'm sure there's something about "windows print subsystems are pretty terrible and we should excise them from anything we can" and "reduce code to reduce bugs" but like.... There's no technical reason it can't

happytoexplain• 2 years ago

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 NotSupportedException." No, no, absolutely no - what the author is describing is a hack to support a shitty client. Yes, you have to do this sometimes. No, it is not normal or generalizable advice.

The way they've worded this betrays the internalization of their suffering as a MS developer.

kolektiv• 2 years ago

Broadly speaking I agree with you in principle - but in practice over time you come to realise that there are only shitty clients. They might not intend to be, they might not have started out that way, but time is a destructive thing...

GMoromisato2• 2 years ago

The issue is that sometimes you need to implement an API which existing clients are already using. You can't go back in time and re-compile, much less re-write the clients.

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.

pas2• 2 years ago

well, that seems like an important piece of the contextual puzzle, because the Xbox printing example by itself seems extremely dumb. (issuing/publishing games on Xbox is not a wild wild west of unknown binaries, if someone cannot get the source code for their thing they are very unlikely to get their thing on Xbox. yes, there are probably binary blobs, but still, to me in this context it's ridiculous that instead of a an exception handling wrapper on the application side the platform does these fakes.)

Scarblac• 2 years ago

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.

codexb• 2 years ago

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.

Aaargh203183• 2 years ago

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.

Arainach22• 2 years ago

The "shitty client" was written long ago by a company that is out of business. YOUR customers rely on that client, and if it stops working because of a change you made they will blame you.

kentonv6• 2 years ago

If you are building a software platform which has been adopted by more than a handful of developers then you're going to have some shitty apps, in which case you have to do this stuff. Yes, it is completely normal and generalizable to all platforms that have wide adoption and take backwards compatibility at all seriously.

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.

bitwize• 2 years ago

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 as expected. Even if it means having special memory management code for SimCity so it will work.

lhamil642• 2 years ago

I also took issue with the Xbox example, and I think it's a context issue. When I read it, I interpreted it as an API for new apps/games to use. In that case, they should be testing on an actual Xbox before shipping! And why would the app be trying to print in the first place if it's designed to run on an Xbox?

But I suspect the situation this is being designed for is existing PC apps being ported to an Xbox. OK, in that case I can see fudging the API since there might be obscure corners that the devs didn't think about that try to print. But I'd still say the devs should be testing on an Xbox and make an effort not to attempt to do things when it doesn't make sense for the platform.

xp846• 2 years ago

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.

orange_fritter• 2 years ago

The way they've worded this betrays the internalization of their suffering as a MS developer.

While I feel less strongly about this Xbox/printing example, I remember Bill Gates saying "I reboot my computer every day" which is a similar mindset-- this culture has been forced to adopt a certain form of "hygiene" due to that same culture NOT adopting hygiene preemptively when they built their systems.

ofslidingfeet3• 2 years ago

This mindset is even less ethical than it seems, and I'm not surprised to see it present at microsoft.

Arainach22• 2 years ago

What do you mean by "ethical" here, and why is it unethical to preserve ABI compatability?

chrisjj18• 2 years ago

why is it unethical to preserve ABI compatability?

Straw man. What's unethical here is deceiving the user.

ofslidingfeet3• 2 years ago

I didn't say it's unethical to preserve "ABI compatability." It's the software equivalent of the Chinese government gaslighting everyone while they wait for the dancing grannies to get the hint and go home. It is, in fact, the exact same technique.

And not only that, we're fast approaching the day where we all power on our PCs to discover that you can login with any user you like. And it gives you the list of all users who have a one drive account.

ofslidingfeet3• 2 years ago

This is obviously how they made their recent hit game "authenticator loop" that we all loved so much for a while there, for instance.

forrestthewoods2• 2 years ago

Well, the wrong thing to do is to have the printing functions throw a NotSupportedException. 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 infuriating as a programmer to call a function and not know if it can throw and, if it can, not know what it can throw. It’s a disaster.

I so desperately wish that C++ had Rust’s Result type and pattern matching. std::optional and std::expected are kinda sorta ok, but you really want compiler enforced pattern matching.

What a tragedy.

mike_hock2• 2 years ago

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.

forrestthewoods2• 2 years ago

I’ve never, ever seen a codebase that reliably used noexcept.

boost and Python are my arch-nemesi because they make heavy use of exception errors and it makes the APIs an absolutely miserable nightmare to use.

How do you square that with backward compatibility?

Huh? The same way normal code handles changing function arguments or return types? I have absolutely never relied on exceptions to “future proof” return error types! Yikes.

The only thing I have ever used exceptions for is to escape bad input/data. It gets trapped internally in the “private” API and same result types are returned through the public API.

I would much rather have a return type of Result<T, Exception const*> than T but also maybe it throws or maybe not and you almost definitely forgot to check which is why people do filthy filthy hacks like the OP article.

marshray• 2 years ago

It is absolutely infuriating as a programmer to call a function and not know if it can throw and, if it can, not know what it can throw. It’s a disaster.

Every nontrivial function can fail (in C even a unary operation on an int), it's just a question of whether and how the caller is informed, how easily the failure is to ignore and continue processing in an undefined corrupted state, and what percentage of the code ends up being dead branches for impossible-but-unprovable error paths.

I so desperately wish that C++ had Rust’s Result type and pattern matching.

I'm a fan of Rust too, but what do you think panic() is?

Rust has no concept of code that always succeeds. It's all-but impossible on current CPUs.

https://github.com/search?q=repo%3Arust-lang%2Frust+path%3A%...

https://doc.rust-lang.org/std/result/enum.Result.html#method...

thimp• 2 years ago

It's a crap analogy. Why would you expose a printing API on a device without printing support? Just ifdef it out on the build.

gruez8• 2 years ago

How about an app originally designed for iPhone but is running on an iPad? iPhones can make calls, but iPads can't. Sure, a properly designed iPad app wouldn't try to use the phone functionality, but what if the developer is too lazy to develop a dedicated iPad app? Surely a crappy iPhone app running on iPad is better than no app at all?

alpaca1284• 2 years ago

Wouldn't that be part of Apple's app reviews?

chrisjj18• 2 years ago

Surely a crappy iPhone app running on iPad is better than no app at all?

Bogus comparison. Non-crappy apps are a thing.

Arainach22• 2 years ago

When you have a platform, apps aren't always being rebuilt for it.

There is no "build" because the source code was lost when all of the company's assets were sold off in 2002.

There is no "build" because this is FooManager 6.0, the company that makes FooManger wants everyone to buy FooManager 7.0 and isn't making any further changes to 6.0.

etc. etc. etc.

nearbuy2• 2 years ago

It's an option, but it has its own downsides. It's a cross-platform API.

Someone wants to show some guests some of their photos and videos on their TV through their Xbox. Unfortunately they can't because their app (eg Samsung Gallery or iCloud or whatever) included a print button somewhere.

And with these inert functions, if Microsoft one day adds printing support to the Xbox, it'll just work in the photo app without any update.

mminer237• 2 years ago

Because then you're making every developer make a special build for every device. Most developers aren't going to care enough to make a dedicated Xbox or tablet build. You're just going to make the platform completely dead. It would be much better if all pre-existing apps could mostly run on them.

iamtedd• 2 years ago

the function for installing a printer can return immediately with a result code that means “The user cancelled the operation.”

I hope this is never shown to the user, because one of the most infuriating things that can happen is when the computer tells me that I did something I actually didn't.

xp846• 2 years ago

It would be unlikely that it would be, since to any properly implemented app, the fact that the user cancelled is not an error since it thinks you did it yourself on purpose.

On the other hand, I recall a few years ago (in the days of one of Apple’s least stable Mac OS [X] releases) seeing the message frequently after a random kernel panic “You restarted your computer because of a problem.” And I would be pretty ticked, saying “Nope! YOU restarted yourself. 0% of this was me. I was sitting here and you just died and rebooted.”

They changed it to use passive voice instead, a year or two after that!

benjaminpv3• 2 years ago

Or more broadly, don't do something unbidden on my behalf then complain when it doesn't work. I swear 75% of the times I've daydreamed about a return to a single-tasking OS like DOS was on account of software trying to 'help' me.

maerF0x03• 2 years ago

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 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 :)

PS this analogy works in a lot of domains - If you have actors in a system actively trying to hide their flaws/errors it will be exponentially harder to root them out and solve the issues.

gruez8• 2 years ago

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 comes to the end user, "swallowing errors" is preferable to crashing.

ploxiln• 2 years ago

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!

amelius• 2 years ago

Maybe then raise an assertion error, which only has an effect in development mode.

ryandrake2• 2 years ago

Even as an end user, I hate when my computer seems to be trying to hide something from me. Even if I can't do anything about it, I want to know it's happening. Don't worry, Microsoft. I'm a grown-up and can handle the bad news. If I'm a layman, maybe I just dismiss the dialog and try again. But if I'm a little more of a power user, maybe I'll look up the error message and see if I can start diagnosing or helping.

If you swallow the error message, I'll have zero idea that something is even going wrong! And almost just as bad: if you put up one of those useless infantilizing "oopsie doopsie computer made a poopsie" error messages, I still won't know what went wrong AND I'm being treated like a moron.

I worked for a software company once where our software basically crashed every 2-3 hours of continuous use due to a huge backlog of technical debt, memory leaks, and years of rushing. My manager's solution to this was not to fix the bugs--it was to build a separate "launcher" process that would detect that the application crashed, eat the error messages, and silently re-launch it hoping the user doesn't notice. Way to treat your users with respect...

pjerem• 2 years ago

I’m sorry, maybe the article used the wrong example but the main issue comes from the fact that an Xbox app is trying to print something. It should fail, not for the developer experience, but because to start, there is no way the user would want to print something on an Xbox. Something is already really wrong with your app if it tries to do things like this.

Also he says that apps are developed and tested on PCs and that they could print in this context. I don’t know a single thing about Xbox development but I hope you can run/debug them in the Xbox environment (or a simulation).

Let me hope that nobody is running their Xbox apps/games on Windows APIs at development time and releases them on Xbox without further testing.

thfuran3• 2 years ago

That is a dangerous assumption. Unless you know a great deal about every possible use case, you can't know the potential ramifications of incorrect output. Proceeding from invalid state (which would often be the result of swallowing errors) is essentially undefined behavior.

mey2• 2 years ago

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 desktop where a user has no control of correcting the system code, the final experience is more important that correctness in many cases. It doesn't matter who is "in the wrong". Microsoft learned that it doesn't matter why the BSOD occurred, just that bad software/hardware was giving them the bad reputation.

So yeah, fail fast/halt catch fire on any invalid input/condition is my personal preferred design, but I can see the value in this approach in this environmental context. The important thing here is that context and not applying either dogmatically. Don't take Mr Chen's approach in reactor or HFT designs for example. Fantastic approach for game engines.

PaulHoule2• 2 years ago

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.

creshal• 2 years ago

Microsoft learned that it doesn't matter why the BSOD occurred, just that bad software/hardware was giving them the bad reputation.

But the primary resolution to that problem was to force hardware vendors to write higher quality drivers (or for MS to write good enough default drivers that HW vendors wouldn't need their own), not to hide the BSOD. Technical details were only removed from them 2 decades after MS started fixing drivers.

greatgib2• 2 years ago

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.

vikingerik• 2 years ago

Much of the crappy legacy behavior that Microsoft maintains is the fault of other applications, not themselves.

The classic one is the error code for the file open function. Early DOS would return error codes of only 3, 4, 5, and no more. DOS programs would actually just indirect-jump using the error number as an index into a lookup table of addresses. When Microsoft tried to add any error codes (say 6), the program would jump out into hyperspace since 6 was beyond that lookup table and that memory word could be anything. So Microsoft was stuck folding every possible file open error into code 5, and to this day that's why just about any file error in Windows just says "5 Access Denied". And no, Microsoft couldn't add more error codes and just let the applications break, since then nobody would buy the new operating system versions that their programs wouldn't work on.

derefr4• 2 years ago

The point of the article, in large part, is that when you’re designing an alternative runtime for a new platform, it is up to you what conditions are considered to be errors. Deciding to make a component of the runtime “inert” exists before and above the decision to make the implementation panic.

In this specific case: it is up to Microsoft to decide what the semantics of “printing on an Xbox” are. It could be an error; or it could be something that “could be supported in theory in the future, but for now has no way to actually accomplish it.” This is a design choice, not a development choice.

After all, in theory, you could print on an Xbox — plug in a USB printer, find a “game” that knows how to print (some enhanced port of a Gameboy game that had GB Printer support, maybe?), and tell it to do so. It’s not necessarily, fundamentally an error that a Xbox game is trying to print. You could define it as an error — but that’s a choice like any other, with trade-offs (in this case, to application portability.) You could define it as asking for the user to choose from no options, as the Xbox actually does. You could have the API lie and say it printed something. You could even actually support printing. These are all choices.

It’s only once you’ve made that choice, defining the semantics of “printing on an Xbox” as an error, that it becomes an implementation/debugging problem if that error isn’t thrown — i.e. gets “swallowed.”

freeone3000• 2 years ago

UWP apps that don’t require specifically desktop APIs will run on Xbox — including, for instance, Excel.

RetroTechie3• 2 years ago

In this specific case: it is up to Microsoft to decide what the semantics of “printing on an Xbox” are. It could be an error; or it could be something that “could be supported in theory in the future, but for now has no way to actually accomplish it.” This is a design choice, not a development choice.

Anything wrong with "print to file"? There'd be no dead tree output but (file) output nonetheless & printing as a function should work.

Btw love the title of this article!

WalterBright4• 2 years ago

It has irked me for decades that when the internet connection fails, all you get is a message that it failed. But what failed?

1. the software on your computer

2. the computer's hardware

3. the ethernet cable or wifi

4. the switch

5. the router

6. the cable modem

7. the internet cable to your house

8. the ISP

9. the remote system you're trying to connect to

Nothing has improved for decades.

Am4TIfIsER0ppos• 2 years ago

Add a parallel step there, somewhere, for DNS. My raspberry pi runs pihole but the hardware is failing somehow so the server crashes so DNS lookups fail. All existing connections are fine, direct IPs are fine, locally cached results are fine, but new lookups fail. It is somewhat fun to watch it happen.

flir• 2 years ago

I've been suffering that TODAY.

"Connection Refused No Further Information"

Well thanks pal.

jeroenhd2• 2 years ago

This is something I kind of like about the Microsoft APIs. Their error codes aren't always perfect, but at least they give you some indication where things went wrong.

From MSDN:

An HRESULT value consists of the following fields:
A 1-bit code indicating severity, where zero represents success and 1 represents failure.
A 4-bit reserved value.
An 11-bit code indicating responsibility for the error or warning, also known as a facility code.
A 16-bit code describing the error or warning.

The "reserved value" also includes a bit for non-Microsoft code (which driver vendors and other API producers can use, although I don't know how often they do)

There's a list of common "facilities" here: https://learn.microsoft.com/en-us/openspecs/windows_protocol...

As a regular user, you will see errors like 0x8ACEF00D, but if you decode them, you can get a sense of what part of the system ran into the failure. Compared to the "negative value indicates failure, look up the possible failures and what they mean for every function" approach many other APIs follow, that's a welcome change.

Of course there's no guarantee that Microsoft doesn't return some kind of meaningless internal E_SOMETHING_WENT_WRONG value, but for a lot of APIs, there are details hidden in plain sight. It won't tell you your ISP's fiber has snapped, but it'll tell you if the problem is within the driver, a security limitation, an HTTP error, or a generic network stack issue.

User3456335• 2 years ago

You're making the assumption that it is all caused by hardware or software malfunction in the sending of an IP packet to the target server. However the first step is usually a DNS lookup. A list would look more like this:

1. DNS lookup fails because the DNS server address configured at the computer OR router is incorrect 2. DNS lookup fails because the configured DNS server is down 3. DNS lookup fails because some firewall is blocking requests to it 4. DNS lookup fails because the network was congested 5. DNS lookup fails because of interference in the Wifi channel from other Wifi networks 6. Etc. Etc.

So indeed, usually when the network is down you only get "DNS lookup failed". Because the actual reason may be complicated. Of course, usually it is due to your computer not being connected to a router so usually the error message hints at that (in layperson's terms: not connected to the internet). So that's why browsers hint at it being your connection, i.e. ethernet or wifi.

But there is no way to make sure. All we know is that DNS seems to fail. The reason it fails could be any part of its configuration which is spread out across physical systems and software components.

The best we can say: probably your ethernet/wifi connection. If we trust that none of the other components are failing then it must be your connection that is failing.

It's like trying to find out what's wrong in 1+2+32+4=10. Sure, it seems like the 32 should be a 3. But maybe the 10 should be a 39. There is no way to tell anymore. All we can do is make an educated guess.

WalterBright4• 2 years ago

It's similar to when you try to print something, and nothing happens.

1. is the printer turned on?

2. is the printer out of paper or ink?

3. does the cable have a loose connection?

4. is it the wrong printer driver?

5. do you need to reboot windows?

6. do you need to power cycle the printer?

No help anywhere. You just try things one by one, sacrifice a small animal, and then maybe the printer gods will smile on you and the printer will print.

wvenable3• 2 years ago

I've learned this as "swallowing errors" and IMO it's a poor practice

This is not swallowing errors. This, in the Linux parlance, is not breaking user-space.

There are two ways to handle the situation presented: error out because the machine can never have printers or return an empty list of printers because the machine can never have printers. They're both valid but only one of them doesn't break user-space.

Trollmann• 2 years ago

Agreed this is akin to

  HTTP 200
  {"error": "Not found"}

samatman• 2 years ago

Not at all! It's like porting a program which expects there to be a TCP stack to a system which doesn't have one, and wiring up a component which responds to all HTTP requests with 404 instead of letting it hang on an infinite loop or crash. Say it uses a browser for rendering, but in the original you can also fetch websites, and the assumption is deeply baked into the code.

If your choice is between playing whack-a-mole with all parts of the system which might call out, or just issuing a 404 (after all, if there's no Internet, you're not going to find a web page on it), that's a reasonable way to solve the problem.

h0l0cube2• 2 years ago

This is something that Elixir nailed. The typical idioms for return types are `{:ok, ok_value} | {:error, error_value}`, for which callers can pattern match against and handle appropriately. If fail-fast is desired, many functions will also have a variant signaled by a postfix exclamation mark (e.g., some_function!(...)), that returns `ok_value` or raises an exception.

nonethewiser7• 2 years ago

This is something that Elixir nailed. The typical idioms for return types are `{:ok, ok_value} | {:error, error_value}`, for which callers can pattern match against and handle appropriately.

Agree this is a good pattern. Im not categorically against throwing errors but I like returning errors or the result and then having to check at the caller. Do this in typescript a lot.

perryizgr8• 2 years ago

Not only does it not solve the issue at hand

It does actually. This approach ensures that old apps (whose authors never thought it would run on something called an Xbox) will seamlessly run and perform all functions properly except for printing, which isn't supported on Xbox. Panicking here would mean every older app has to update their code to support Xbox.

stubish• 2 years ago

As a Go programmer, how often do you check if fmt.Print returned an error? You get to assume that stdout and stderr exist for a start, even if your code is being run in an environment where that makes no sense. And what is the correct behavior for your software when IO errors start happening when you print? In a dev environment, probably crash. But in a production environment? A customers workstation?

The article isn't so much about swallowing exceptions, but more about designing the system so you don't have to raise exceptions.

nonethewiser7• 2 years ago

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.

That kind of thing intuitively sounds bad. But I guess of this is in a space shuttle I would take that back.

Wowfunhappy2• 2 years ago

Think of it like an emulator. The goal of DosBox is to provide Doom with the environment it wants so that it will run. That will necessitate some amount of lying.

kelnos3• 2 years ago

Completely disagree. Getting back at the programmer for making a mistake isn't what matters. Presenting the best experience possible to your users is all that matters.

If the user clicks on a print button in an app on the Xbox, and the app crashes (possibly losing some of the user's data), that's a bad experience for the user. Why do that to them just to stick it to the programmer?

And on top of that, now some developer at some company (often not even the person who initially made the bad assumptions about printing) has now been called in on a weekend by their boss to scramble to fix the issue and push out a new release. Why do that to people?

Regardless, also consider the API contract. If the printing API isn't documented to throw any exceptions, and you start doing that, you're breaking the contract. You can't blame the programmer for not considering platforms without printing support; you've documented that API as always returning something without blowing up.

But that's still irrelevant; don't break user code just because you can, or because it's more expedient for you to do so.

Your Go example is completely unrelated; you're talking about making things blow up at testing time, which I agree is the right thing to do. But that's also when you have full control over the code and the testing. If a third-party platform API starts behaving in ways you didn't expect it to behave, that's a whole other thing.

l33t7332273• 2 years ago

You're mostly not supposed to use it or recover from it at run time

Are you serious? I thought a key principle of Go was to handle panics in a layered way at runtime

maerF0x03• 2 years ago

in my experience that's partly true (it's a judgement call and lies on a spectrum). Like a HTTP server should handle panics in handler code so as to not crash the other go routines handling requests. Or maybe a long running queue worker (eg reading off SQS) should recover from a single go routine handling a message (assuming it can recover and handle the next message successfully).

But it'd be way out of scope to put a recover block outside every function call just incase it did a runtime error: index out of range [1] with length . In this way its much different than try catch in languages that explicitly call out what they throw

admax88qqq• 2 years ago

Nah I don't think this counts as swallowing errors.

There's nothing wrong or buggy about the printing API on Xbox returning a list of no printers instead of an exception.

It's essentially the Null Object design pattern. Even Go implements this in the way that a zero list can still be accessed an jsut behaves as an empty list.

Or in unix how /dev/null exists, which implements the file API but doesn't do anything. This is way nicer than fixing every UNIX program to handle stdout not existing sometimes.

inglor_cz• 2 years ago

I wonder if Go's panic was inspired by Symbian OS User::Panic, an uncatchable sort of exception that was only used in situations when the programmer screwed up. It would kill the entire thread.

Not limited to testing time, though.

anonacct37• 2 years ago

I love and hate this. On a visceral level I don't like dealing with issues via malicious compliance.

OTOH I absolutely agree this is a good call if your goal is for more users to be able to run more software on your platform, even if printing is broken.

elwell• 2 years ago

With this behavior, when the app tries to print, it will ask the user to select a printer, and show an empty list.

I see Microsoft has not learned from 30 years: https://www.reddit.com/r/hacking/comments/djvzd/windows_nt_l...

nonethewiser7• 2 years ago

That os amazing

1970-01-01• 2 years ago

This is also very good for security. Correctly dismissing an API call means these programs aren't able to go off and do extra naughty things.

leaf89372• 2 years ago

throw checked exception so that xbox will have to handle the exception. xbox implementation can donothing if they want.

Arwill• 2 years ago

Sometimes this kind of error handling is the cause of program slowdowns. So the API fails, but the program retries anyway, and so fails again endlessly. The user doesn't see anything from this happening, only that "the app is slow". Windows is plagued by this kind of behaviour. Its both what the article suggests can cause this, but throwing and ignoring exceptions can have this effect too.

The goal, IMO, would be to force the app not to try (or not to try once it failed) something that is bound to fail.

leaf89372• 2 years ago

if possible, throw checked exception which must be handled.

zxcvbnm• 2 years ago

Wrong, errors should not go unnoticed, let alone helping them to propagate. Cascading effects should be kept on a short leash. System takes one step in the wrong direction, kill it. The two most miserable things are, things not happening and there's no feedback on why, and, the other extreme, when things are overengineered and no one can predict where problems might cascade to.

12_throw_away• 2 years ago

lord grant me the confidence of someone who reads a thoughtful explanation of a problem and its solution by Raymond Chen and responds with "Wrong, "

B1FF_PSUVM• 2 years ago

It's hilarious, Chen has been doing this right - on the bleeping internets for all to see - for thirty years and we've greenhorns going "Nah, mate, you're doing it wrong."

thrwwycbr• 2 years ago

Maybe you should build an operating system from scratch, keep building it for more than 25 years and then come back to revise your comment?

patapong• 2 years ago

Hmmm I see and appreciate the idea behind this. That said, it seems confusing for the user to be shown an empty list of printers if no printers can be installed on the platform. In my opinion, it would be preferable to show the user a dialog that says "This platform does not support printing" and, once they dismiss the dialog, inform the program that the user cancelled the print action.

city41• 2 years ago

I agree, using the empty list to communicate to the user the situation is making an assumption about the user. A lot of users have never set up or dealt with printers ever. I can say for sure that an empty list of printers would confuse a lot of people in my household.

o11c• 2 years ago

Making it a linker error doesn't even seem to be considered. Xbox is a separate target so a recompile is needed anyway ...

Arainach22• 2 years ago

No, it's not - that's the point of the Universal Windows Platform - compile once, put in store, run everywhere.

This also isn't just about new platforms. If you have a desktop operating system and want to change the behavior of an API in a future version, you have to do this same process.

Throw6away• 2 years ago

Microsoft’s MDM APIs will return a 500 (server error) on a VM if you try to get a list of wireless networks, instead of the saner approach of returning an empty list. The same APIs will return a 418 (I’m a teapot) if you mistakenly try to add an already-existing setting, instead of just updating it as one might expect. They get points for originality, but don’t follow the advice in this article.

yau8edq12i• 2 years ago

Microsoft has around 238000 employees according to Wikipedia. That they are not all strictly following Raymond Chen's latest blog post isn't surprising.

philipwhiuk• 2 years ago

I'm sorry but that code sample is an incomprehensible eyesore.

And I've written PHP4.

LASR• 2 years ago

What's crazy is that I didn't even realize it until you pointed it out. I've been doing Win32 for so long it's like reading the green symbols in The Matrix. This all looks "normal" to me.

zerr• 2 years ago

Besides being unreadable, it is well known that Win32 API code is unwritable. It is only copy/paste-able.

jeroenhd2• 2 years ago

Windows headers like uppercase. They also like very explicit types, as far as the language accepts them, of course. For example, HRESULT really is just a 32 bit integer with special rules (top bits set subsystem that cause the error, bottom bits set error code, hence the conversion function for best practice).

Stripping out the Windows types and compile-time validation and the wrappers, and picking non-Windows error codes, you can turn the code into more Unix-like C++:

    int32_t CreateWidget(int32_t* widget)
    {
        *widget = nullptr;
        return ECANCELED;
    }
    
    int32_t GetWidgetAliases(wchar_t* aliases, uint16_t capacity, uint16_t* actual)
    {
        *actual = 0;
        return EBADF;
    }
    
    int32_t EnableWidget(int32_t widget, bool value)
    {
        return EBADF;
    }
    
    int32_t Close(int32_t widget)
    {
        return EBADF;
    }

However, this code may not function if you're building for 32-bit Windows and it may not work on every compiler; it just assumes certain bit sizes that the API only guarantees in the form of typedefs.

sirspacey2• 2 years ago

I missing what the magic is here.

This seems like a long way to go for “we know that this device is an Xbox and Xbox doesn’t support printing, let’s tell the user”

Only it doesn’t tell the user. It leads them down a path implying implementation is possible.

On the other hand, I now know why so many issues I’ve troubleshooted on MS products end in tears and complete confusion as to why they wouldn’t just say “this is not a feature you can use on this device.”

filleduchaos3• 2 years ago

This seems like a long way to go for “we know that this device is an Xbox and Xbox doesn’t support printing, let’s tell the user”

You're missing the fact that Xbox can run apps developed for (desktop) Windows, and that the scenario in the article is about the platform <-> end user relationship and does not involve the app developer at all.

sirspacey2• 2 years ago

Ok, appreciate the insight.

Doesn’t the platform: 1. Know that is a windows app 2. Know that it is Xbox

So it could override the “print” request with a user appropriate notification?

comicjk• 2 years ago

I agree. The author's description of what is "reasonable" sounds like a blueprint for many of my late nights struggling with Windows:

"apps that assume that printing works will still behave in a reasonable manner: You’re just on a system that doesn’t have any printers and all attempts to install a printer are ineffective."

Maybe the underlying assumption is that the users will give up before spending an "unreasonable" amount of time on these tar pit features.

crooked-v• 2 years ago

Doing nothing correctly sounds like hard work. I guess I'll try it out sometime later when I have more energy.

denysvitali• 2 years ago

Wouldn't it be simpler to just create a "Save to PDF" printer and use that in the Xbox? This way the API stays compatibile, and it actually makes it useful

SillyUsername• 2 years ago

Exception safety guarantees have been around for decades and were originally defined by David Abrahams who was on the C++ standards board.

As the author is a Microsoft employee I'm a little surprised no attribution or reference to the original author of (the levels of) exception safety guarantees which his article partly describes.

Raymond Chen (article author) is refering to the "no throw guarantee" in his article as opposed to one of the other outcomes https://en.m.wikipedia.org/wiki/Exception_safety

laserbeam2• 2 years ago

Good: average apps continue to work as expected.

Bad: good apps can't know what's supported or not.

What's missing from the article is adding a way for apps to detect and handle this behavior. (Using the printer example) There should also be some API that tells me "printing is not supported on this platform" somehow. If I want to be a good software developer I should hide the print button in the UI in a very predictable way.

It's great that if I actually try to print nothing happens as expected. It's bad if I can't detect that printing would never work, and I should be able to do that via at least some function call that doesn't magically noop.

josephcsible• 2 years ago

From the article:

Now, you probably also want to add a function to check whether printing even works at all. Apps can use this function to hide the Print button from their UI if they are running on a system that doesn’t support printing at all.

laserbeam2• 2 years ago

Somehow I missed that. Thanks!

cratermoon• 2 years ago

This is also like Null Object or Special Case pattern. It simplifies error handling, and because error handling code is often poorly tested it ends up being a big source of catastrophic failures. Making illegal states unrepresentable, or as John Ousterhout puts it: define errors out of existence: https://wiki.tcl-lang.org/page/Define+Errors+Out+of+Existenc...

armchairhacker• 2 years ago

Slightly tangential, this reminds me of how to `sleep` in JavaScript without using async: https://stackoverflow.com/a/37575602

Wowfunhappy2• 2 years ago

“I asked for a widget, and you gave me one, and then when I showed it to you, you said, ‘That’s not a widget.’ This API is gaslighting me!”

The entire point, it should be noted, is to gaslight the app. But the API must be good enough at gaslighting that the app doesn't discover the lie.

johngossman• 2 years ago

The point the critics of this piece seem to be missing is that there is not an exceptional case here that needs an error to be thrown. There are NO printers attached to the device (in this case by definition), and an app should cleanly handle that case, not crash. You wouldn’t throw an exception on a laptop just because it couldn’t reach the printer.

PennRobotics• 2 years ago

If you want a clear, modern example of a popular non-Microsoft product doing printer availability wrong, it's gnome-control-center.

Add a printer in Settings. While the printer is installing, click over to the "Color Profiles" tab. If you time it right, gnome-control-center will crash. If you dive into the details, you see that it was trying to enumerate the available printers (it knows one should be there) but that info doesn't exist yet. So it just crashes.

Thankfully, the fix is to just wait a few seconds for GNOME to finish installing the printer and restart Settings. Still, it's the principal app responsible for making your desktop work correctly as an end user with some unknown computing background. In a perfect world, this app should never crash.

It's hard to think about edge cases. It's even harder to imagine your handling of edge cases has its own edge cases. Right or wrong, at least the author is thinking deeper than "bad app, needs to be rewritten to support Wayland"

evnc• 2 years ago

From the title alone, I initially thought this would be about meditation.

_Algernon_• 2 years ago

The only reason an X-box doesn't support printing is because Microsoft has defined it as such. A x-box is just as capable to print as the Windows machine in the next room over from a hardware perspective.

Which means this "solution" to a stupid, self-created problem is stupid. I bet this workflow will lead at least a handful of people to ask "How do I add a printer to my X-box?" instead of "Fuck the app crashed, better not do that again."

Microsoft has so much stupid, corporate driven decision making. Can't wait for it to follow in IBM's footsteps.

yungporko2• 2 years ago

"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 is exactly the kind of stupid shit that makes me hate using anything from microsoft. on what planet is this desirable behaviour? is it beyond microsoft's capability to just show a message saying "Printing is not available on Xbox"?

fullstackchris• 2 years ago

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.

What? Why would you ever do this? This post screams of "can't see the forest from the trees"

Sure, now you don't have your app crashing, and instead you have this weird state of seeming like you can print but ultimately can't, wasting users time and perhaps frustrating them even more.

Why not literally just show a dialog like "printing is not supported from an Xbox"? Easy to develop, easy to understand... everyone wins.

korginator• 2 years ago

There are widely used practices for API design and versioning that work well today. While this article's kludgy approach to backward compatibility may have been passable a few decades ago, this is a terrible way to approach the problem in 2024, specially with services & APIs being deployed & distributed across platforms.

The article illustrates how *not* to build APIs.

akho• 2 years ago

This starts with an Xbox not being able to print, while being able to run computer applications. The correct solution is not to have that. There is no graceful way to recover otherwise, no matter how "inert" you are.

saagarjha2• 2 years ago

Everyone here is hung up on doing "nothing" and handling "errors" and I feel like the post does a poor job explaining how it is not just swallowing everything that's going wrong and going kumbaya. The actual context is that the author is doing emulation/compatibility for software that will not change, and that's very different from most contexts. This is especially confusing because Microsoft often blurs the line between the two themselves, and that's not actually what is being talked about here at all.

Really, emulation is all about telling lies. Your Xbox doesn't actually have a way to attach a printer. You're running a game on Linux, not Windows. Your fake iPhone is actually a ARM server in AWS. The point here is that if you're going to lie you better do so convincingly. That's because you need existing applications to still work! When Microsoft says you can port your existing Windows app to Xbox the promise for the Windows app was that it would be able to print, and so Xbox needs to lie for that to happen.

This is very different from a normal error. If a program does a use after free, and you silently pretend the bug doesn't exist by working around it, then you're not doing anything correctly. That's because nobody promises that your existing use after frees will be bug-for-bug compatible on a new platform.

lucianbr5• 2 years ago

There may be times where you need to make an API do nothing. It’s important to have it do nothing in the correct way.
For example, Windows has an extensive printing infrastructure. But that infrastructure does not exist on Xbox. What should happen if an app tries to print on an Xbox?

It says nowhere that the context is doing emulation for software that will not change. You just assume that because it supports the position you like. In fact, everything written applies to a program that I might write tomorrow for an XBox, and try to print something. There is nothing that designates this behavior only for old, unmaintained software.

buttercraft4• 2 years ago

If you write a program tomorrow, use the API correctly and this issue will not apply to you. This is for apps that aren't well written and don't check for the capabilities ahead of time.

saagarjha2• 2 years ago

I generally advocate for things crashing early, for reference. I just happen to work on emulators and compatibility shims a lot, much like what Microsoft is offering here.

sporkland• 2 years ago

I wish the concept of dev mode and prod mode were baked deeper into all language runtimes/libraries.

e.g. before going to production with real users these cases should error as hard as possible, including potentially logging crashing the program to make the program errors super visible. Then in production it should largely log these things in error logs and keep chugging along.

And not like an environment variable with conditions. Something as first class as changing the standard exception and fatal calls behaviors.

mrcsharp• 2 years ago

What a weird thread of comments this was. There are clearly people who just don't like anything Microsoft does.

The point of the blog is to make the process of bringing apps (UWP) to XBOX be frictionless: no recompile required, no messy ifdefs, none of that extra work. The App would "just work". Then, it's up to the developers to start adjusting the app to fit the XBOX platform more. The important thing here is that the developer was able to bring the app with no effort to XBOX. This is good for both the platform and the developer.

To the user, it's a clear signal that they can't print since the list of printers are empty. But most importantly for them, the app did not crash or show the most hated error: "oops something went wrong. Try again later."

Is that message a better experience for the user? No.

Sure, the developers can recompile the app and add a more descriptive message but then we're back to square one.

PH95VuimJjqBqy• 2 years ago

I honestly feel like 95% of the people in this thread didn't understand the article.

for example, accusations of swallowing errors. That's not the point, not at all.

empuxr• 2 years ago

As a Platform Engineer who has to work with Azure on a daily basis, I am so tired of their APIs and services making exceptions left and right, sometimes for their own shitty clients. The result is a Patchwork product suite, services never work as expected but deviate from their documentation (or rather what they are claiming is their documentation).

The Daily Azure shit Mastodon account has more than enough examples of this. For example https://azsh.it/167 or https://azsh.it/107

This article made me realize while Azure is the way it is - unreliable and broken.

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

Related Stories