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

I&#x27;ve learned this as &quot;swallowing errors&quot; and IMO it&#x27;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.<p>This is one thing I like about Go&#x27;s panic. You&#x27;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&#x27;s ok, we all do), and it&#x27;s time to figure out where and how to fix it :)<p>PS this analogy works in a lot of domains - If you have actors in a system actively trying to hide their flaws&#x2F;errors it will be exponentially harder to root them out and solve the issues.

People are reacting negatively as expected, but stuff like this is exactly why you can click on a file that was written in Word &#x27;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&#x27;t do it at all.

I find nothing quite as frustrating as UIs that suggest a device <i>could</i> exist, but it&#x27;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.

&gt; With this behavior, when the app tries to print, it will ask the user to select a printer, and show an empty list.<p>I see Microsoft has not learned from 30 years: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;hacking&#x2F;comments&#x2F;djvzd&#x2F;windows_nt_login_hack_gif&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;hacking&#x2F;comments&#x2F;djvzd&#x2F;windows_nt_l...</a>

The <i>specific thing</i> the author is suggesting is correct (components should suffer before users do), but I take great offense to their framing. &quot;There may be times where you need to make an API do nothing.&quot; &quot;The wrong thing to do is to have the printing functions throw a Not­Supported­Exception.&quot; 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.<p>The way they&#x27;ve worded this betrays the internalization of their suffering as a MS developer.

Everyone here is hung up on doing &quot;nothing&quot; and handling &quot;errors&quot; and I feel like the post does a poor job explaining how it is not just swallowing everything that&#x27;s going wrong and going kumbaya. The actual context is that the author is doing emulation&#x2F;compatibility for software that will not change, and that&#x27;s very different from most contexts. This is especially confusing because Microsoft often blurs the line between the two themselves, and that&#x27;s not actually what is being talked about here at all.<p>Really, emulation is all about telling lies. Your Xbox doesn&#x27;t actually have a way to attach a printer. You&#x27;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&#x27;re going to lie you better do so convincingly. That&#x27;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 <i>needs</i> to lie for that to happen.<p>This is very different from a normal error. If a program does a use after free, and you silently pretend the bug doesn&#x27;t exist by working around it, then you&#x27;re not doing anything correctly. That&#x27;s because nobody promises that your existing use after frees will be bug-for-bug compatible on a new platform.

I love and hate this. On a visceral level I don&#x27;t like dealing with issues via malicious compliance.<p>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.

What a weird thread of comments this was. There are clearly people who just don&#x27;t like anything Microsoft does.<p>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 &quot;just work&quot;. Then, it&#x27;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.<p>To the user, it&#x27;s a clear signal that they can&#x27;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: &quot;oops something went wrong. Try again later.&quot;<p>Is that message a better experience for the user? No.<p>Sure, the developers can recompile the app and add a more descriptive message but then we&#x27;re back to square one.

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.

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&#x27;s intention as well as you can, and go ahead. Errors are bad. Users don&#x27;t want errors.<p>I thought we learned from that experience. Apparently not.

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

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

The only reason an X-box doesn&#x27;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.<p>Which means this &quot;solution&quot; to a stupid, self-created problem is stupid. I bet this workflow will lead at least a handful of people to ask &quot;How do I add a printer to my X-box?&quot; instead of &quot;Fuck the app crashed, better not do that again.&quot;<p>Microsoft has so much stupid, corporate driven decision making. Can&#x27;t wait for it to follow in IBM&#x27;s footsteps.

I missing what the magic is here.<p>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”<p>Only it doesn’t tell the user. It leads them down a path implying implementation is possible.<p>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.”

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.

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 &quot;This platform does not support printing&quot; and, once they dismiss the dialog, inform the program that the user cancelled the print action.

Slightly tangential, this reminds me of how to `sleep` in JavaScript without using async: <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;37575602" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;37575602</a>

Exception safety guarantees have been around for decades and were originally defined by David Abrahams who was on the C++ standards board.<p>As the author is a Microsoft employee I&#x27;m a little surprised no attribution or reference to the original author of (the levels of) exception safety guarantees which his article partly describes.<p>Raymond Chen (article author) is refering to the &quot;no throw guarantee&quot; in his article as opposed to one of the other outcomes <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Exception_safety" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Exception_safety</a>

&gt; Well, the wrong thing to do is to have the printing functions throw a Not­Supported­Exception. The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available. When run on an Xbox, the exception will probably go unhandled, and the app will crash.<p>Exceptions are such a catastrophically bad idea in almost all cases.<p>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.<p>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.<p>What a tragedy.

I wish the concept of dev mode and prod mode were baked deeper into all language runtimes&#x2F;libraries.<p>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.<p>And not like an environment variable with conditions. Something as first class as changing the standard exception and fatal calls behaviors.

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: <a href="https:&#x2F;&#x2F;wiki.tcl-lang.org&#x2F;page&#x2F;Define+Errors+Out+of+Existence" rel="nofollow">https:&#x2F;&#x2F;wiki.tcl-lang.org&#x2F;page&#x2F;Define+Errors+Out+of+Existenc...</a>

Why &#x2F;wouldn&#x27;t&#x2F; I want to print something from my Xbox?

There are widely used practices for API design and versioning that work well today. While this article&#x27;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 &amp; APIs being deployed &amp; distributed across platforms.<p>The article illustrates how *not* to build APIs.

&gt; the function for installing a printer can return immediately with a result code that means “The user cancelled the operation.”<p>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&#x27;t.

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

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 &quot;inert&quot; you are.

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

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

&gt; “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!”<p>The entire point, it should be noted, <i>is</i> to gaslight the app. But the API must be good enough at gaslighting that the app doesn&#x27;t discover the lie.

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).<p>The Daily Azure shit Mastodon account has more than enough examples of this. For example <a href="https:&#x2F;&#x2F;azsh.it&#x2F;167" rel="nofollow">https:&#x2F;&#x2F;azsh.it&#x2F;167</a> or <a href="https:&#x2F;&#x2F;azsh.it&#x2F;107" rel="nofollow">https:&#x2F;&#x2F;azsh.it&#x2F;107</a><p>This article made me realize while Azure is the way it is - unreliable and broken.

&gt; 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.<p>What? Why would you ever do this? This post screams of &quot;can&#x27;t see the forest from the trees&quot;<p>Sure, now you don&#x27;t have your app crashing, and instead you have this weird state of seeming like you can print but ultimately can&#x27;t, wasting users time and perhaps frustrating them even more.<p>Why not literally just show a dialog like &quot;printing is not supported from an Xbox&quot;? Easy to develop, easy to understand... everyone wins.

I&#x27;m sorry but that code sample is an incomprehensible eyesore.<p>And I&#x27;ve written PHP4.

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

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

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

&quot;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.&quot;<p>This must be satire. Otherwise I can&#x27;t comprehend how something as infuriating as this could be presented as a good or smart thing to do UX-wise

if possible, throw checked exception which must be handled.

And they ask why we&#x27;re cynical. I&#x27;m about done with this whole &quot;personal computing&quot; fad.

Your ecosystem has gone so complex that you can&#x27;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&#x27;s none available).<p>If that&#x27;s really the suggestion of product and engineering leadership at MSFT no wonder all their products...err...work as designed.

Good: average apps continue to work as expected.<p>Bad: good apps can&#x27;t know what&#x27;s supported or not.<p>What&#x27;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 &quot;printing is not supported on this platform&quot; somehow. If I want to be a good software developer I should hide the print button in the UI in a very predictable way.<p>It&#x27;s great that if I actually try to print nothing happens as expected. It&#x27;s bad if I can&#x27;t detect that printing would never work, and I should be able to do that via at least some function call that doesn&#x27;t magically noop.

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&#x27;s no feedback on why, and, the other extreme, when things are overengineered and no one can predict where problems might cascade to.

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

I understand the logic here, and I&#x27;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&#x27;re doing here is lying to the user and the developer. Maybe that&#x27;s justified in isolation, but now this lie is one more bit of &quot;hidden state&quot; 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&#x27;re completely lost in them and have no idea what reality is.<p>I have a feeling that &quot;solutions&quot; like this are part of why an increasing number of my computing problems take the form of, &quot;I tried to take an action, nothing happened. No error, no activity, nothing.&quot;, 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&#x27;t work, and when you try to figure out why, all the OS does is shrug.