if possible, throw checked exception which must be handled.
If you're just going to sit there doing nothing, at least do nothing correctly
131–140 of 356 posts
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#132Earlier quoted context omitted.
Error design depends on context. For most of the systems I work on, fail fast on request for anything out of spec is the correct design. B2B/Microservices/API focused systems. Windows however has focused on bending over backwards to provide compatibility (including memory patching popular software that was broken, like Simcity https://arstechnica.com/gadgets/2022/10/windows-95-went-the-... ). In the context of a user…
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 close to common sense, end users don’t care which monkey(s) threw in the wrench if they encounter an error, just that some entity did.
The only caveats I can think of are that it must prominently display that it’s running in a “compatibility mode” and that any encrypted subsystems can’t revert to a lower standard of encryption, which may render the application unusable anyways depending on how tightly integrated it is.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#133Earlier quoted context omitted.
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 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” is called, it could not only return the “user cancelled it” status but also display an error message. It depends on the implementation details and whether someone probably 20 years ago foresaw the need for a modal but not fatal system error message to be triggered by that API call. Which again is not in the today developer’s control.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#134Earlier 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,…
I think this is the critical piece that should determine how you handle the error. If the API, as used by the client, when the client was programmed, was expected to potentially throw NotSupportedException or return an error code, then doing so sounds like the right way to go. Throwing/erroring is part of the API contract and the client should handle NotSupportedException.
If the API was never expected to throw NotSupportedException or return an error code, then all of a sudden starting to throw in a future release breaks the API contract, and the client cannot be expected to handle it sensibly.
EDIT: Duh! My comment is useless. This was the exact conclusion that the article came to, too. So instead of reading this comment chain, just finish the article :)
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#135Earlier quoted context omitted.
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…
> 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.
This doesn't pass the sniff test because
1. There's documented error codes that go all the way up to 16k: https://learn.microsoft.com/en-us/windows/win32/debug/system...
2. There's file related error codes way above 5, eg. ERROR_FILE_EXISTS 80 (0x50)
The general gist of your comment is correct though. Suppose windows didn't have file locks before and they were adding it. Returning an error code like FILE_LOCKED or whatever would be much more descriptive, but would also require all existing code to handle this error case. With that in mind returning ACCESS_DENIED makes perfect sense, even if programs aren't using jump tables.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#136Why /wouldn't/ I want to print something from my Xbox?
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
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#137The specific thing the author is suggesting is correct (components should suffer before users do), but I take great offense to their framing. "There may be times where you need to make an API do nothing." "The wrong thing to do is to have the printing functions throw a NotSupportedException." No, no, absolutely no - what the author is describing is a hack to support a shitty client. Yes, you have to do this sometim…
The issue is that sometimes you need to implement an API which existing clients are already using. You can't go back in time and re-compile, much less re-write the clients. It all depends on how the clients are currently using the API. If the clients are already testing for NotSupportedException, then that's what you should return. But if not, you need a different approach.
well, that seems like an important piece of the contextual puzzle, because the Xbox printing example by itself seems extremely dumb. (issuing/publishing games on Xbox is not a wild wild west of unknown binaries, if someone cannot get the source code for their thing they are very unlikely to get their thing on Xbox. yes, there are probably binary blobs, but still, to me in this context it's ridiculous that instead of a an exception handling wrapper on the application side the platform does these fakes.)
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#138> Well, the wrong thing to do is to have the printing functions throw a NotSupportedException. 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…
> if it can throw and, noexcept. Granted, it may not have the annotation but still not throw in reality, but a Rust function can also declare a Result return type but never actually return an error. > if it can, not know what it can throw How do you square that with backward compatibility? If you declare what you can throw, what do you or any of your transitive dependencies do when they want to change their implement…
I’ve never, ever seen a codebase that reliably used noexcept.
boost and Python are my arch-nemesi because they make heavy use of exception errors and it makes the APIs an absolutely miserable nightmare to use.
> How do you square that with backward compatibility?
Huh? The same way normal code handles changing function arguments or return types? I have absolutely never relied on exceptions to “future proof” return error types! Yikes.
The only thing I have ever used exceptions for is to escape bad input/data. It gets trapped internally in the “private” API and same result types are returned through the public API.
I would much rather have a return type of Result than T but also maybe it throws or maybe not and you almost definitely forgot to check which is why people do filthy filthy hacks like the OP article.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#139Wrong, 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.
Re: If you're just going to sit there doing nothing, at least do nothing correctly
#140I'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…
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 that they could print in this context. I don’t know a single thing about Xbox development but I hope you can run/debug them in the Xbox environment (or a simulation).
Let me hope that nobody is running their Xbox apps/games on Windows APIs at development time and releases them on Xbox without further testing.