Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

151–160 of 356 posts

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

#151

Post by Arainach »

mrguyorama wrote: post #136
Arainach wrote: post #76

Earlier quoted context omitted.

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

It's an x64 CPU running most of Windows with plentiful and fully supported USB ports. Why CAN'T I print from my Xbox? I can print with my phone, so why not my Xbox? I'm sure there's something about "windows print subsystems are pretty terrible and we should excise them from anything we can" and "reduce code to reduce bugs" but like.... There's no technical reason it can't

It's not running "most of Windows". In particular, as far as I know (no insider knowledge), it's not running any of the Win32 APIs (USER, etc.). So that rules out any printers which require coordination with their desktop app (which, to be honest, to get full functionality is still a shockingly high number of them). It's highly unlikely the XBox hypervisor implements any of the printing APIs, even UWP because this is a video game console, and not only does almost no one own a networked printer, an even smaller group of essentially no one has a printer, opens documents on their video game console, and wants to print them.

Features aren't free. What Xbox feature would you drop to have an engineer go implement printing APIs on them? Is that the best use of their time?

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

#152

Post by chrisjj »

daveoc64 wrote: post #21
Jabrov wrote: post #4

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

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?

But the first option is not "this app can't run on your Xbox". It is "This app possibly cannot run after trying to print".

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

#153

Post by skykooler »

Aaargh20318 wrote: post #111
Scarblac wrote: post #36

Earlier quoted context omitted.

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, not a shitty client, just one that was written before you decided to make this change. Has the Xbox ever supported printing? Why even have these APIs? Just don’t offer them at all in the Xbox SDK. You shouldn’t be able to compile code that tries to call these when targeting Xbox.

It's an API that also targets Windows. Apps that use it can run on both platforms.

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

#154

Post by chrisjj »

toss1 wrote: post #59
Jabrov wrote: post #4

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

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.

> I.e.: Fail gracefully.

There's no grace in misleading the user and wasting his time.

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

#155

Post by jacobgkau »

pjerem wrote: post #140
gruez wrote: post #102

Earlier quoted context omitted.

>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 c…

I’m sorry, maybe the article used the wrong example but the main issue comes from the fact that an Xbox app is trying to print something. It should fail, not for the developer experience, but because to start, there is no way the user would want to print something on an Xbox. Something is already really wrong with your app if it tries to do things like this. Also he says that apps are developed and tested on PCs and…

The point is that the UWP allows running apps developed and tested on PCs on an Xbox. It's for the user's convenience (not having to wait on developers to port to Xbox) as much as the developer's (not having to port to Xbox).

If a user wants to run an app on their Xbox, telling them "no, the developer didn't test this on the Xbox, so I'm not going to let you do that because you might try to print and get confused about it" isn't what the user wants to hear.

When the app tries to print because the developer was "lazy" and didn't test on Xbox, telling them "I'm going to crash your app now because you clicked Print, even though I know you're on an Xbox and I could just ignore that" also isn't helpful to the user.

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

#156

Post by chrisjj »

xp84 wrote: post #133
Contortion wrote: post #78

Earlier quoted context omitted.

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.

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…

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

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

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

#157

Post by chrisjj »

gruez wrote: post #46
thimp wrote: post #35

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

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?

> Surely a crappy iPhone app running on iPad is better than no app at all?

Bogus comparison. Non-crappy apps are a thing.

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

#158

Post by PaulHoule »

elevatedastalt wrote: post #142
PaulHoule wrote: post #115

Earlier quoted context omitted.

It's hard to overstate how hard Microsoft has worked to maintain backwards compatibility. Recently I had to read an old Access file and where I work we still keep Office '97 around for this purpose and it is quite amazing that it installs and works just fine on Win 11, Clippy works just fine, in fact all the other lame-ass things Office '97 does to take over your desktop all still work even if they don't quite visual…

It's hard to overstate*

Fixed

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

#159

Post by marshray »

forrestthewoods wrote: post #29

> 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. Exceptions are such a catastrophically bad idea in almost all cases. It is absolutely infuriatin…

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

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

#160

Post by chrisjj »

mike_hock wrote: post #42
Analemma_ wrote: post #3

I understand the logic here, and I'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're doing here is lying to the user and the developer. Maybe that's justified in isolation, but now this lie is one more bit of "hidden state" you have to keep track of in furthe…

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 "soluti…

> So what's your solution then? Break all apps simultaneously that do not have extensive tests

No test required. Just try... catch.

> for gracefully handling cases that were impossible when they were created?

You can never know they are impossible. That is why you have a top-level try...catch.

Post reply on HN