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.
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.
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.
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 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. 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.”
> 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.
> 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.
I don't know what program he would be talking about, but I think if Raymond Chen is writing about something, it's usually because it is a real problem that was encountered, even if he's writing about it as if it was hypothetical to avoid naming the software in question.
He generally avoids naming non-Microsoft software he's found bugs in.
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.