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

181–190 of 356 posts

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

#181

Post by wvenable »

lucianbr wrote: post #5

Once upon a time it was considered a great strategy for browsers to make the best effort to display a page, even if the html code had errors. Just try to guess the author's intention as well as you can, and go ahead. Errors are bad. Users don't want errors. I thought we learned from that experience. Apparently not.

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 tag, instead of just best-effort rendering the page, then every new browser feature would have been smothered in the cradle.

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

#182

Post by Trollmann »

maerF0x0 wrote: post #91

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…

Agreed this is akin to

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

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

#184

Post by samatman »

Trollmann wrote: post #182
maerF0x0 wrote: post #91

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…

Agreed this is akin to HTTP 200 {"error": "Not found"}

Not at all! It's like porting a program which expects there to be a TCP stack to a system which doesn't have one, and wiring up a component which responds to all HTTP requests with 404 instead of letting it hang on an infinite loop or crash. Say it uses a browser for rendering, but in the original you can also fetch websites, and the assumption is deeply baked into the code.

If your choice is between playing whack-a-mole with all parts of the system which might call out, or just issuing a 404 (after all, if there's no Internet, you're not going to find a web page on it), that's a reasonable way to solve the problem.

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

#185

Post by nerdponx »

kentonv wrote: post #30
tsimionescu wrote: post #2

I find nothing quite as frustrating as UIs that suggest a device could exist, but it's not there right now. I then have to spend time to discover that these devices are not supported, and that screen was just some mock someone came up with.

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

> Sure, but you'd be more frustrated if your app just crashed.

I don't know about that. If it crashes, I might not try that thing again.

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

#186

Post by h0l0cube »

maerF0x0 wrote: post #91

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…

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.

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

#187

Post by sirspacey »

I missing what the magic is here.

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”

Only it doesn’t tell the user. It leads them down a path implying implementation is possible.

On the other hand, I now know why so many issues I’ve troubleshooted on MS products end in tears and complete confusion as to why they wouldn’t just say “this is not a feature you can use on this device.”

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

#188

Post by delta_p_delta_x »

repler wrote: post #149
apetresc wrote: post #116

Earlier quoted context omitted.

Before the new '.docx`, '.xslx', etc. formats, when it was still just .doc, .xsl, etc., the document format was (as I've heard it told) essentially just a memory dump of Word/Excel's state for that document at the time you saved. And since it's easy to imagine that serializing/deserializing such a complex thing might not be always 100% perfectly idempotent, it would indeed happen that just the act of opening a file w…

the new formats are actually zip archives believe it or not

They are ZIP archives... of XML. That's what the 'x' stands for in '.docx', '.xlsx', '.pptx', etc; it is Office Open XML[1].

[1]: https://en.wikipedia.org/wiki/Office_Open_XML#:~:text=Office....

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

#189

Post by city41 »

patapong wrote: post #144

Hmmm I see and appreciate the idea behind this. That said, it seems confusing for the user to be shown an empty list of printers if no printers can be installed on the platform. In my opinion, it would be preferable to show the user a dialog that says "This platform does not support printing" and, once they dismiss the dialog, inform the program that the user cancelled the print action.

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.

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

#190

Post by delta_p_delta_x »

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.

? Why even have these APIs?

Xbox essentially runs Windows. Therefore, the Windows API is available on Xbox.

Post reply on HN