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

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.

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.

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.

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.

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.

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

Agreed this is akin to

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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"

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.

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.

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?

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

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.

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.

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.

What do you suggest as an alternative?

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

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!

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

No, 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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

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?

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.

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.

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

What did you think we learned?

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

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.

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.

Go type in:

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

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

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

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

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.

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.

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.

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?

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.

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, "

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?

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.

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.

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

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;
    }
    

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.

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.

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

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.

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!

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.

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.

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.

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.

That os amazing

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