This is exactly what the browsers have been doing for decades and why the developer experience with html/css is infuriating.
It seems like a decent approach when you're working with an existing tech stack and not some shiny new technology that has every sorted appropriately.
At first I was like "just return an empty list of printers and let the user think there might be printers? Are you mad?" But than I was like "Well, that's what I would do in an API as well"
Html/css/JavaScript is one of the most highly compatible and prolific stacks to ever exist. I like to say that JavaScript has succeeded where Java was trying to be.
They didn't succeeded because they were good, but because they were popular.
Browser devtools are very inferior to java/.net devtools, except the network tab from the browser, only thing the language I gave as example lack.
JavaScript, until recently, was literally the only option. It's a nightmare of a language littered with bear traps and pitfalls.
Lol
I've seen far too manny error messages claiming I did something I most certainly didn't do. This seems like a good way to make those far more prolific.
Isn't this better to understand about what the program is trying to do, which a user really only has a passing influence on
This seems wrong to me. Existing paradigms like try catch or returning result codes enable handling these situations gracefully and in an informed manner. Making an inert api as is suggested here means that now you have an api that doesn’t behave as expected but without an explanation why.
“The app was probably only tested against a PC so an exception would be unhandled” means that they did not implement it well against a PC. There are a bunch of possible reasons you’d get an exception while adding a printer on a PC, and I can’t imagine that the correct behavior would be to crash whatever it is you’re doing.
This is exactly what the browsers have been doing for decades and why the developer experience with html/css is infuriating.
It seems like a decent approach when you're working with an existing tech stack and not some shiny new technology that has every sorted appropriately. At first I was like "just return an empty list of printers and let the user think there might be printers? Are you mad?" But than I was like "Well, that's what I would do in an API as well"
Html/css/JavaScript is one of the most highly compatible and prolific stacks to ever exist. I like to say that JavaScript has succeeded where Java was trying to be.
They didn't succeeded because they were good, but because they were popular.
Browser devtools are very inferior to java/.net devtools, except the network tab from the browser, only thing the language I gave as example lack.
JavaScript, until recently, was literally the only option. It's a nightmare of a language littered with bear traps and pitfalls.
Lol
I've seen far too manny error messages claiming I did something I most certainly didn't do. This seems like a good way to make those far more prolific.
Isn't this better to understand about what the program is trying to do, which a user really only has a passing influence on
This seems wrong to me. Existing paradigms like try catch or returning result codes enable handling these situations gracefully and in an informed manner. Making an inert api as is suggested here means that now you have an api that doesn’t behave as expected but without an explanation why.
“The app was probably only tested against a PC so an exception would be unhandled” means that they did not implement it well against a PC. There are a bunch of possible reasons you’d get an exception while adding a printer on a PC, and I can’t imagine that the correct behavior would be to crash whatever it is you’re doing.
Be alert - the world needs more lerts