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

121–130 of 356 posts

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

#121

Post by ryandrake »

gruez wrote: post #102
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…

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

Even as an end user, I hate when my computer seems to be trying to hide something from me. Even if I can't do anything about it, I want to know it's happening. Don't worry, Microsoft. I'm a grown-up and can handle the bad news. If I'm a layman, maybe I just dismiss the dialog and try again. But if I'm a little more of a power user, maybe I'll look up the error message and see if I can start diagnosing or helping.

If you swallow the error message, I'll have zero idea that something is even going wrong! And almost just as bad: if you put up one of those useless infantilizing "oopsie doopsie computer made a poopsie" error messages, I still won't know what went wrong AND I'm being treated like a moron.

I worked for a software company once where our software basically crashed every 2-3 hours of continuous use due to a huge backlog of technical debt, memory leaks, and years of rushing. My manager's solution to this was not to fix the bugs--it was to build a separate "launcher" process that would detect that the application crashed, eat the error messages, and silently re-launch it hoping the user doesn't notice. Way to treat your users with respect...

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

#122

Post by derefr »

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…

The point of the article, in large part, is that when you’re designing an alternative runtime for a new platform, it is up to you what conditions are considered to be errors. Deciding to make a component of the runtime “inert” exists before and above the decision to make the implementation panic.

In this specific case: it is up to Microsoft to decide what the semantics of “printing on an Xbox” are. It could be an error; or it could be something that “could be supported in theory in the future, but for now has no way to actually accomplish it.” This is a design choice, not a development choice.

After all, in theory, you could print on an Xbox — plug in a USB printer, find a “game” that knows how to print (some enhanced port of a Gameboy game that had GB Printer support, maybe?), and tell it to do so. It’s not necessarily, fundamentally an error that a Xbox game is trying to print. You could define it as an error — but that’s a choice like any other, with trade-offs (in this case, to application portability.) You could define it as asking for the user to choose from no options, as the Xbox actually does. You could have the API lie and say it printed something. You could even actually support printing. These are all choices.

It’s only once you’ve made that choice, defining the semantics of “printing on an Xbox” as an error, that it becomes an implementation/debugging problem if that error isn’t thrown — i.e. gets “swallowed.”

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

#123

Post by TillE »

derefr wrote: post #112
codexb wrote: post #101

Earlier quoted context omitted.

It depends. Did the API document that it could raise an exception if printing isn't supported? Is that unhandled in the client? Then yes, it's a shitty client. If you're talking about making backwards-incompatible breaking changes to an API, that's another thing.

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 Not­Supported­Exception 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.

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

#124

Post by xp84 »

eastbound wrote: post #73
lucianbr wrote: post #25

Earlier quoted context omitted.

That every single behavior that attempts to guess the users's intent becomes a relied upon part of the software, and this over time grows to an impossible amount of cruft. See this, hilariously hosted also by microsoft: https://techcommunity.microsoft.com/t5/discussions/funny-sto... > And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to b…

In 2024, so we still have websites that are served differently depending on the User Agent? Could we possibly do away with the User-Agent header, or reset it to a simple “Chrome 150.01”?

Meh. For all the silliness, it’s not that hard to parse one for the main purpose it should be used for, which is determining in aggregate what platforms your users use. As such, we still need things like OS in there anyway. So it wouldn’t get quite that short.

Also I’m amused checking mine that the user agents still say “Intel Mac OS X” even on Apple silicon. I guess they were afraid someone’s parser would think we are on PowerPC without that!

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

#125

Post by vikingerik »

greatgib wrote: post #118
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 the Microsoft way to do things, this is why their products like Windows are so crappy, full of bugs, unexpected behaviors and a big dump of shit of legacy behaviors expected on top of a lot other legacy behaviors on top of another 1989 legacy behavior that every forgot.

Much of the crappy legacy behavior that Microsoft maintains is the fault of other applications, not themselves.

The classic one is the error code for the file open function. Early DOS would return error codes of only 3, 4, 5, and no more. DOS programs would actually just indirect-jump using the error number as an index into a lookup table of addresses. When Microsoft tried to add any error codes (say 6), the program would jump out into hyperspace since 6 was beyond that lookup table and that memory word could be anything. So Microsoft was stuck folding every possible file open error into code 5, and to this day that's why just about any file error in Windows just says "5 Access Denied". And no, Microsoft couldn't add more error codes and just let the applications break, since then nobody would buy the new operating system versions that their programs wouldn't work on.

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

#126

Post by xp84 »

Arainach wrote: post #49
fidrelity wrote: post #6

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.

What is "your ecosystem" here? Part of running a platform is that the code running on it is written by other people, not you, and that your customers will be relying on that code. When the software your customers are relying on breaks because of a change you made, it doesn't matter whose "fault" it is. It's broken, it broke because of something you did, and you have burned customer trust - not the trust of whoever wr…

It is so obvious from reading these comments here who is not, and would never ever want to be, a platform engineer. It’s hard for some people to grasp that you need to not only interact with, but thoroughly accommodate, software written by others whom you don’t control (often due to the one-way direction of time flow).

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

#127

Post by mminer237 »

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.

Because then you're making every developer make a special build for every device. Most developers aren't going to care enough to make a dedicated Xbox or tablet build. You're just going to make the platform completely dead. It would be much better if all pre-existing apps could mostly run on them.

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

#128

Post by pas »

bakugo wrote: post #84
paxys wrote: post #10

People are reacting negatively as expected, but stuff like this is exactly why you can click on a file that was written in Word '97 or a game that was compiled for MS-DOS three decades ago and it opens on your computer exactly as expected. Backwards compatibility is always messy. You either do it imperfectly or don't do it at all.

I assume the negative reactions are due to the large Apple user base on HN. Most of these people are likely so used to being told "this software was built for a version of your OS released 2 years ago so you can't use it anymore, tough shit", they've come to expect it.

nah, it's because all of this is just lip service. windows11 is getting worse and worse.

and cool that Mr Chen thinks about UX and compatibility, but MS as whole does not really. important business apps got special treatment, and that's it. (MS and its corporate entourage solved this mostly by providing Windows and "security" patches for it, for a lot of money.)

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

#129

Post by derefr »

TillE wrote: post #123
derefr wrote: post #112

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 Not­Supported­Exception 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.

Clients are not expected/required, however, to behave correctly in the face of unknown error codes that did not exist or have defined semantics at SDK-version-selection time.

Actual exceptions — in languages that have them — are a bit different, in that they “do” something by default: they propagate and unwind unless they’re caught. And so, new (unchecked, if in a language where that’s relevant) exceptions can be introduced after the fact under the presumption that the runtime’s default behavior for propagating unknown exceptions will kick in, and that this will trigger the desired result for applications that weren’t written in awareness of that particular exception.

Error codes aren’t like that; they have no default semantics as a class, only explicit default semantics per function and/or per algebraic error-code type, if-and-where documented as such. New error codes simply aren’t meant to be introduced in most APIs, unless those APIs have rules about e.g. generalized default handling for defined code ranges that new codes can be later slotted into.

Basically, error codes are weak enums. If you’re writing a dynamic-link library (or a runtime — same thing, basically), you’re not supposed to add new potential values to an enum used as a return value: client code will likely have been written to switch on the value with the known options as cases, and your new value won’t be in there.

Post reply on HN