[Contortion]

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.

[xp84]

User spends two hours creating content. User hits print.

1. App crashes back to the desktop/Home Screen/etc

2. App can’t find any printers. User cancels and saves the document, prints elsewhere.

You really think option 1 is better?

Also, none of this precludes the ability to display a message. He’s talking about the system calls themselves and how they should respond. I suppose if the call for the “Add Printer Wizard” is called, it could not only return the “user cancelled it” status but also display an error message. It depends on the implementation details and whether someone probably 20 years ago foresaw the need for a modal but not fatal system error message to be triggered by that API call. Which again is not in the today developer’s control.

[chrisjj]

> 1. App crashes back to the desktop/Home Screen/etc

Why do think it would crash, rather that simply return to main loop?

[xp84]

It might return to the main loop if you throw a NoPrintingOnXboxException… if and only if the author of the app has decided to catch a broad enough exception in that exact place in the code, and handles it gracefully. Good practice to always handle any exception that might be thrown, but it’s not always obvious in the past where there might be a chance for an exception to be thrown. For instance, the printing subsystem itself can’t be missing, can it??

So anyway, the platform vendor can’t be sure the above situation is perfectly handled by every app, so the entire point of the article is “given you must technically comply with the published API specifications, how can you construct the least harmful and least disruptive response to every request sent to this fully-removed system component.”

This whole exercise is basically constructed in order to usually guarantee the outcome you’re suggesting: to cause the app to just return to its normal functioning without doing the impossible thing.

[toss1]

So it 'simply returns to main loop'. I.e., the user hits [Print] and then it maybe flickers and goes back to the home screen.

How in heck is that more useful than App reporting that "I can’t find any printers"?

[Contortion]

Because "I can't find any printers" suggests that printing is possible if only you set up your printer correctly, rather than suggesting the print function doesn't work.

By showing that no printers can be found the app is misleading the user to think there's an issue external to the app that they need to solve themselves.

[chrisjj]

> the user hits [Print] and then it maybe flickers and goes back to the home screen.

And reports the exception.

[trealira]

The idea is to accommodate apps that just didn't handle the exception, or handled the exception by crashing, probably because they only tested the app on a PC, where printing was always available.

> 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. Even if the app tried to catch the exception, it would probably display a message like “Oops. That went badly. Call support and provide this incident code.”

[chrisjj]

> probably because they only tested the app on a PC

If they made an app only for PC, why would they test it on Xbox??

If they wanted their app to run on Xbox, why would they not make an Xbox version, and test it there??

RC's scenario is taking an app made for only Windows PC and running it on Xbox. I wonder if he has found even one example which permits this in the licence.