191–200 of 356 posts
I'm sorry but that code sample is an incomprehensible eyesore. And I've written PHP4.
throw checked exception so that xbox will have to handle the exception. xbox implementation can donothing if they want.
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.
Earlier quoted context omitted.
> why is it unethical to preserve ABI compatability? Straw man. What's unethical here is deceiving the user.
There is no deception. There are no printers, and that's what the API returns.
"NotSupportedException" is there for a reason.
Earlier quoted context omitted.
> 1. App crashes back to the desktop/Home Screen/etc Why do think it would crash, rather that simply return to main loop?
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"?
And reports the exception.
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.
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.
Earlier quoted context omitted.
In the context of the article, no, the existing API never threw (or was documented as capable of throwing) NotSupportedException. The article: > The app that the user installed on the Xbox was probably tested primarily, if not exclusively, on a PC, where printing is always available. I.e. there is no concept in the (desktop) Windows printing subsystem of printing as a feature not being available; on desktop Windows,…
The mention of NotSupportedException is a little confusing because that's a .NET thing, and the rest of the article is talking about Win32, which is a plain old C API where exceptions don't exist. I guess he's implicitly talking about a C# API built on top of Win32. It's entirely correct to return error codes, and any client is expected to handle that.
Correct. The error `ERROR_CANCELLED` is defined in WinErr.h and it's translated via `HRESULT_FROM_WIN32` in the same[1]. It was this change pointed out in `CreateWidget` to get around returning the null pointer that he was suggesting would be better to make the API inert.
[1] - https://learn.microsoft.com/en-us/windows/win32/api/winerror...
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…
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.