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

211–220 of 356 posts

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

#211

Post by flir »

WalterBright wrote: post #150
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 has irked me for decades that when the internet connection fails, all you get is a message that it failed. But what failed? 1. the software on your computer 2. the computer's hardware 3. the ethernet cable or wifi 4. the switch 5. the router 6. the cable modem 7. the internet cable to your house 8. the ISP 9. the remote system you're trying to connect to Nothing has improved for decades.

I've been suffering that TODAY.

"Connection Refused No Further Information"

Well thanks pal.

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

#212

Post by laserbeam »

Good: average apps continue to work as expected.

Bad: good apps can't know what's supported or not.

What's missing from the article is adding a way for apps to detect and handle this behavior. (Using the printer example) There should also be some API that tells me "printing is not supported on this platform" somehow. If I want to be a good software developer I should hide the print button in the UI in a very predictable way.

It's great that if I actually try to print nothing happens as expected. It's bad if I can't detect that printing would never work, and I should be able to do that via at least some function call that doesn't magically noop.

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

#213

Post by jeroenhd »

WalterBright wrote: post #150
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 has irked me for decades that when the internet connection fails, all you get is a message that it failed. But what failed? 1. the software on your computer 2. the computer's hardware 3. the ethernet cable or wifi 4. the switch 5. the router 6. the cable modem 7. the internet cable to your house 8. the ISP 9. the remote system you're trying to connect to Nothing has improved for decades.

This is something I kind of like about the Microsoft APIs. Their error codes aren't always perfect, but at least they give you some indication where things went wrong.

From MSDN:

> An HRESULT value consists of the following fields:

> A 1-bit code indicating severity, where zero represents success and 1 represents failure.

> A 4-bit reserved value.

> An 11-bit code indicating responsibility for the error or warning, also known as a facility code.

> A 16-bit code describing the error or warning.

The "reserved value" also includes a bit for non-Microsoft code (which driver vendors and other API producers can use, although I don't know how often they do)

There's a list of common "facilities" here: https://learn.microsoft.com/en-us/openspecs/windows_protocol...

As a regular user, you will see errors like 0x8ACEF00D, but if you decode them, you can get a sense of what part of the system ran into the failure. Compared to the "negative value indicates failure, look up the possible failures and what they mean for every function" approach many other APIs follow, that's a welcome change.

Of course there's no guarantee that Microsoft doesn't return some kind of meaningless internal E_SOMETHING_WENT_WRONG value, but for a lot of APIs, there are details hidden in plain sight. It won't tell you your ISP's fiber has snapped, but it'll tell you if the problem is within the driver, a security limitation, an HTTP error, or a generic network stack issue.

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

#214

Post by josephcsible »

laserbeam wrote: post #212

Good: average apps continue to work as expected. Bad: good apps can't know what's supported or not. What's missing from the article is adding a way for apps to detect and handle this behavior. (Using the printer example) There should also be some API that tells me "printing is not supported on this platform" somehow. If I want to be a good software developer I should hide the print button in the UI in a very predicta…

From the article:

> Now, you probably also want to add a function to check whether printing even works at all. Apps can use this function to hide the Print button from their UI if they are running on a system that doesn’t support printing at all.

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

#215

Post by mook »

miki123211 wrote: post #180
delta_p_delta_x wrote: post #163

Earlier quoted context omitted.

> It's hard to overstate how hard Microsoft has worked to maintain backwards compatibility. Here's a pretty detailed list: - It is possible to target Windows XP SP3 (released 2008, EOL 2014, 10 years ago) from Windows 11 and Visual Studio 2022[1] using C++23. Windows 2000 can be targeted with a little more setup[2]. Windows 2000 is 24 years old this year. - It is possible to run a binary written for and compiled in W…

I wish they included an 8086 emulator so that old software compiled for DOS would still run. It worked on 32 bit systems until 32 bit support was dropped, which only happened a few years ago. That was due to Intel's virtual 8086 mode, which is not available if your CPU is running in 64 bit (long) mode. Modern computers are fast enough for the emulation overhead to be negligible, even if you don't do any fancy JIT tri…

At least you can still do this with third-party software like https://github.com/otya128/winevdm I guess? I imagine Microsoft doesn't see the returns for it to develop something they'll have to support for decades more…

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

#216

Post by tinix »

Am4TIfIsER0ppos wrote: post #205
WalterBright wrote: post #150

Earlier quoted context omitted.

It has irked me for decades that when the internet connection fails, all you get is a message that it failed. But what failed? 1. the software on your computer 2. the computer's hardware 3. the ethernet cable or wifi 4. the switch 5. the router 6. the cable modem 7. the internet cable to your house 8. the ISP 9. the remote system you're trying to connect to Nothing has improved for decades.

Add a parallel step there, somewhere, for DNS. My raspberry pi runs pihole but the hardware is failing somehow so the server crashes so DNS lookups fail. All existing connections are fine, direct IPs are fine, locally cached results are fine, but new lookups fail. It is somewhat fun to watch it happen.

Keep going... ...

Try: ISP router intercepts DNS and drops the record because your company put private addresses on public DNS and the router has rebind protection.

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

#217

Post by EnigmaFlare »

Am4TIfIsER0ppos wrote: post #205
WalterBright wrote: post #150

Earlier quoted context omitted.

It has irked me for decades that when the internet connection fails, all you get is a message that it failed. But what failed? 1. the software on your computer 2. the computer's hardware 3. the ethernet cable or wifi 4. the switch 5. the router 6. the cable modem 7. the internet cable to your house 8. the ISP 9. the remote system you're trying to connect to Nothing has improved for decades.

Add a parallel step there, somewhere, for DNS. My raspberry pi runs pihole but the hardware is failing somehow so the server crashes so DNS lookups fail. All existing connections are fine, direct IPs are fine, locally cached results are fine, but new lookups fail. It is somewhat fun to watch it happen.

Windows has a tool to diagnose network problems, and it's usually completely useless but I think DNS not working is something it does identify.

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

#218

Post by cratermoon »

This is also like Null Object or Special Case pattern. It simplifies error handling, and because error handling code is often poorly tested it ends up being a big source of catastrophic failures. Making illegal states unrepresentable, or as John Ousterhout puts it: define errors out of existence: https://wiki.tcl-lang.org/page/Define+Errors+Out+of+Existenc...

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

#219

Post by ofslidingfeet »

Arainach wrote: post #54
ofslidingfeet wrote: post #26

This mindset is even less ethical than it seems, and I'm not surprised to see it present at microsoft.

What do you mean by "ethical" here, and why is it unethical to preserve ABI compatability?

I didn't say it's unethical to preserve "ABI compatability." It's the software equivalent of the Chinese government gaslighting everyone while they wait for the dancing grannies to get the hint and go home. It is, in fact, the exact same technique.

And not only that, we're fast approaching the day where we all power on our PCs to discover that you can login with any user you like. And it gives you the list of all users who have a one drive account.

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

#220

Post by thfuran »

Arainach wrote: post #166
thfuran wrote: post #145

Earlier quoted context omitted.

That is a dangerous assumption. Unless you know a great deal about every possible use case, you can't know the potential ramifications of incorrect output. Proceeding from invalid state (which would often be the result of swallowing errors) is essentially undefined behavior.

This isn't invalid state. They're not telling the app about a fake corrupt printer, they are using the API contact to represent the truth (there is no printer you can use) in a way the app already has to support

But I was responding to a general statement.
Post reply on HN