151–160 of 212 posts
Earlier quoted context omitted.
I think it’s cute you think most developers let exceptions rise. Most developers I notice just catch the error right away and make the function return something non-sensible like a 0 for a string value function. Slightly better developers just let the exceptions bubble. The rare breed looks at what exceptions are being thrown, decides which ones to handle at which stack level, and repackages them as needed when the e…
Gotta love these though: catch {};
Earlier quoted context omitted.
When did we stop building software for the "Power User" persona? I don't disagree that there are some (many?) people who start screaming and running in circles when they see an error code, but not every user is like that. You don't have to be a dev to care any the distinction between a system doing its job and silently failing. Why not have some indication that there's smoke coming out from the engine?
Related: the boot scroll. most of the time the scroll of boot messages is harmless and when the system fails to boot it is very very useful to see where. yet the design types hated it. and now no desktop orientated OS shows a boot scroll, opting for a near useless spinner instead. Opinion: I quite like the scroll, I think it comforting to see what the machine is doing. I think this is why sim city put a fake one in t…
Earlier quoted context omitted.
Oh yeah, I still have a 404 page that's padded with comments because its only contents are a title and an image.
base64 inline your image with the HTML and you should be well past that threshold. It's preferable to not make additional requests (like for an image) on an error page - in case the requested server is at fault - breaking the error page.
And if the server has broken so badly it can't send out that image, then I have much bigger worries than an ugly 404 page.
Earlier quoted context omitted.
>Users have no business seeing error codes. Those are for devs. Hiding them away in devtools is a very good thing. I can't say I agree. That would be a good idea in a world where users never encountered errors in normal circumstances, but in fact computers don't work very well and users encounter errors on a regular basis. Using computers is a skill. It takes study. You can either pretend that it doesn't, giving user…
Even more terrifying for the uninitiated back in the day: fatal error
Earlier quoted context omitted.
In my experience, people hate when cars just flash a "check engine" light. It is impossible to tell the difference between "probably OK but get it looked at", "might leave you stranded", and "might literally explode". Cars show error codes every few months or years and there's nothing the average driver can do to fix them. Computers show errors on a daily basis and most of them are trivially fixable.
The parent post says "different error lights" and that might be indicative of experience with European cars. In, say, an Audi, there are 3 or 4 different subsystem lights, with yellow indicating a "get it looked at" issue and red a "stop now" problem. And "might literally explode" usually results in an engine shutdown. > Computers show errors on a daily basis and most of them are trivially fixable As they say, "citat…
(Not just snarky - this does fix a large percentage of errors regular users encounter)
Earlier quoted context omitted.
In my experience, people hate when cars just flash a "check engine" light. It is impossible to tell the difference between "probably OK but get it looked at", "might leave you stranded", and "might literally explode". Cars show error codes every few months or years and there's nothing the average driver can do to fix them. Computers show errors on a daily basis and most of them are trivially fixable.
I despise that check engine light for exactly that reason. It would be much more helpful if the car also displayed the error code that made the light turn on. Then I'd know how urgent the issue is and whether I need to take it to the shop. But then, I'm a dev, not a normal person.
The annoying part for folks used to having control (eg power users) is that someone else decided that that was enough info for drivers. If you want the power-user car UI, you'll need to get out of the driver's seat and put on your mechanic hat. (Like sibling comment who purchased an ODBC reader.)
Earlier quoted context omitted.
>Users have no business seeing error codes. Those are for devs. Hiding them away in devtools is a very good thing. I can't say I agree. That would be a good idea in a world where users never encountered errors in normal circumstances, but in fact computers don't work very well and users encounter errors on a regular basis. Using computers is a skill. It takes study. You can either pretend that it doesn't, giving user…
Even more terrifying for the uninitiated back in the day: fatal error
Edit: Is the blue screen of death still a thing these days? I haven't actually used Windows in a decade.
Earlier quoted context omitted.
When did we stop building software for the "Power User" persona? I don't disagree that there are some (many?) people who start screaming and running in circles when they see an error code, but not every user is like that. You don't have to be a dev to care any the distinction between a system doing its job and silently failing. Why not have some indication that there's smoke coming out from the engine?
My current pet example for the trend of hiding more and more details from users is an issue I recently had with Doordash. I was trying to place an order, and it kept failing with a red banner stating "something went wrong" (I'm paraphrasing as I don't recall the exact verbage, but it was one of those completely worthless error messages) Pop open dev tools ... the server is returning something about a graphql error. S…
Earlier quoted context omitted.
For anyone interested, here's a bookmarklet to view the current page's HTTP status code (makes a new request): javascript:(function()%7Bjavascript%3A(function()%20%7B%0A%20%20var%20xhr%20%3D%20new%20XMLHttpRequest()%3B%0A%20%20xhr.onreadystatechange%20%3D%20function()%20%7B%0A%20%20%20%20if%20(xhr.readyState%20%3D%3D%3D%204)%20%7B%0A%20%20%20%20%20%20alert('HTTP%20Status%20Code%3A%20'%20%2B%20xhr.status)%3B%0A%20%20%…
For suspicious types (including me): javascript:(function(){javascript:(function() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (xhr.readyState === 4) { alert('HTTP Status Code: ' + xhr.status); } }; xhr.open('GET', window.location.href, true); xhr.send(); })();})();