101–110 of 212 posts
Earlier quoted context omitted.
> users have no business seeing anything People like you are the reason users cannot work a file system, download an image, or even read a short text message. You retard the users' progress.
If I wield that much power then I really ought to be paid more.
Earlier quoted context omitted.
Power users haven't become lazy. The middle ground for power users has disappeared. Now it's a split between "everything is so dumbed down and hidden behind fifteen layers of clicks" and "setting up and caring for your system is a second job in addition to your regular job".
On the flip side, how difficult is it to open dev tools, flip to the network tab, and look at your status code return(s) as a power user? As a power user, it never struck me as a high vertical.
My day job is C++ app and driver code for rather complex systems yet when I open browser dev tools my eyes glaze over. There is plenty of middle ground of people who are technical but are not web or browser developers.
Does anyone still remember the days when a certain browser would ignore what the server sent with a 404 page unless it was larger than 512 bytes? Yeah, I'm happy with the browser just showing what I send it without trying to second guess the content.
Do you remember when the AskBar would intercept 404 pages and display suggestions for pages you might really be looking for, “just to help you”? And then Oracle shipped the AskBar into the Java installers.
(I'm not sure there's any way to find the HTTP status code in a modern Firefox environment short of using web developer tools. It's not in places like 'Page Info' as far as I can see.) I'm old enough to remember times before browsers showed 'friendly' error messages, and a 500 response from a server would display a '500 Server Error' message to the user. Users hated it. They'd panic and think they'd broken the websit…
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?
1996 or 1997. I can't narrow it down further.
Shortly after that, they actively became hostile to power users. Just play with your dumb little consumer appliance like you're supposed to.
The author is wrong, browser behaviour does change significantly in one major way: errors are not cached. Or much more importantly, errors incorrectly returned with 200/OK success codes are cached, semi-permanently breaking your site. If you've get helpdesk staff telling customers to "clear their browser cache", this is one common reason why this "works" as a fix. Please, I beg you: stop being "nice". Stop catching e…
Letting an uncaught exception error reach the user is generally bad. It risks exposing secrets / confidential information to the user and any returned client side secrets risk getting into intermediary caches. The biggest risk is the user input being returned in the response creating an XSS (cross site scripting) risk. This is a very common source of reflected XSS vulnerabilities. You should always catch exceptions l…
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 error cannot be handled that deep in that stack due to a lack of context. Then they write framework-level exception handlers for errors that rise to the top because they cannot be corrected at a higher stack level to give users specific error messages with user-correctable actions without revealing anything sensitive. “Your image is too small, wanker.”
Chrome outright refuses to show the HTML of a 500 response in favor of its own dinosaur animation or some garbage, or did that change?
(I'm not sure there's any way to find the HTTP status code in a modern Firefox environment short of using web developer tools. It's not in places like 'Page Info' as far as I can see.) I'm old enough to remember times before browsers showed 'friendly' error messages, and a 500 response from a server would display a '500 Server Error' message to the user. Users hated it. They'd panic and think they'd broken the websit…
(I'm not sure there's any way to find the HTTP status code in a modern Firefox environment short of using web developer tools. It's not in places like 'Page Info' as far as I can see.) I'm old enough to remember times before browsers showed 'friendly' error messages, and a 500 response from a server would display a '500 Server Error' message to the user. Users hated it. They'd panic and think they'd broken the websit…
Yet Windows still frequently shows Error "0x0000F001" without elaborating at all
So in a way, they are already "elaborating" the type of error - as well as a single 32-bit integer in C can "elaborate" over an error, that is, not a lot.
For all their faults dotnet and java make it really easy to not mangle up the stack trace.
Earlier quoted context omitted.
> users have no business seeing anything People like you are the reason users cannot work a file system, download an image, or even read a short text message. You retard the users' progress.
If a user is using your web application normally and ends up with an error, it is an application error. Be it a 401, 403, validation error, 500, 429, whatever, it is not an actual user fault but it is a problem within the application. Once you have this realization, what's the advantage of showing the proper error code to the user? Whatever it is, it's not in his power to fix it
While code fixes are not in their power to do, changing their behavior, or waiting for a better internet connection (i.e. "something went wrong" actually means "go log in to the hotel wifi") are things in their power.
(I'm not sure there's any way to find the HTTP status code in a modern Firefox environment short of using web developer tools. It's not in places like 'Page Info' as far as I can see.) I'm old enough to remember times before browsers showed 'friendly' error messages, and a 500 response from a server would display a '500 Server Error' message to the user. Users hated it. They'd panic and think they'd broken the websit…
There must be a middle ground between "Something went wrong, please try again later :)" and "TypeError: Cannot read property 'submit' of null" when performing an action. I sometimes hear the "best of both worlds" is something like logging all errors while showing optimistic errors to the users on frontend. This is somewhat fine for errors that happen on the backend, but catching browser errors is tricky because exten…
I don't know that there's a lot of useful middle ground between your two examples though. By definition, a UI can't really give actionable advice on how to fix an error that it isn't programmed to expect.