51–60 of 137 posts
Unfortunately the majority of internet users aren't trained in the art of reading HTTP status codes I think the majority know what 404 is, and possibly 403, but I agree about the more obscure ones. That said, I don't think it's a bad idea to rely on the "default exception handling behaviour" that the majority of users, even non-computer-literate ones, will have: they'll retry a few times, see that it doesn't work, an…
I quite liked the windows 0x800*** hex error numbers, though some were more useful than others.
Earlier quoted context omitted.
> Somehow I doubt people faced with this error message really were amused by the reference to the old Amiga OS errors.... I'll bet whoever put that in there feels extra silly about misspelling "meditation", too.
It looks like the spelling was fixed a while ago, does that mean fastly is running an old version of varnish?
Reminds me of the quintessential tweet about error messages https://twitter.com/cherrikissu/status/972524442600558594?s=...
Right up there with Slack etcs fake loading messages "Gearing up the dildonator" "Implicating the fairies" "Hogtying George Bush" Dude - just give me a spinner or a progress bar, and if something errors during the load out give me some sort of stack trace or error ID I can use to help
I'm a principal at AWS and spent years dealing with this on CloudFront and Route 53. A lot right, and a little off, in the post. Yes, we should definitely communicate to the viewer what's happened and appropriate next steps if any. But there are a handful of challenges that Ive not seen reasonably solved. The first problem is that different viewers need different context, which is especially true for service provider…
Very true, at the individual error level. That said, Fastly fixed the entire issue in less time than it would have taken AWS to update the status page to the blue diamond, so there’s that.
Earlier quoted context omitted.
these seem solvable. there's no reason that a good error message AND pertinent support information are mutually exclusive. show them both. show the errors that make sense for that action and that error. no one is saying that there should be a small list of "approved" errors that everyone would see. show what makes sense in that situation, and don't show something that doesn't help. you don't need to have prophetic in…
Showing the error itself only opens the provider to information disclosure - with the various automated infrastructure monitoring systems running on Fastly or CF they know when and where errors are happening with full traces that help them debug. > there's no reason that a good error message AND pertinent support information are mutually exclusive. show them both As the OP stated, there is quite literally nothing sup…
I also agree with GP's point that extremely vague error messages are aggravating. Maybe I did something stupid / unexpected, and with a usable error message I'll be able to fix it on my own. Like sending the wrong file format, or whatever.
I absolutely hate when a system will just say "there's an error". And having cute animals or phrases doesn't change the fact that the error is useless. This is one of the reasons why I absolutely hate working with Windows. "An error occurred. Call your sysadmin". Right. I'm the sysadmin. What now?
This also trains users to never say what's wrong when they call for support. "Yeah, there's an issue with [thing]. What issue? It doesn't work. Oh, of course. There's only exactly one failure mode, so I'll get right on it."
I work in operations and get those fairly often even from people who should know better (software engineers and such) and I find it frustrating to no end that I always have to pull information from them even when there are clear error codes. So no, hiding this kind of info serves absolutely no purpose.
Earlier quoted context omitted.
Even if there’s usually nothing the user can do I still like to have all the stack traces, etc visible - because sometimes there’s enough of a hint that you can get a workaround. A number of DNS failures I’ve worked around with the hosts file.
You've worked around server-side DNS failures?
Or if the host name has .eu.domain or something else indicating a geographic location changing that can get around a localized failure sometimes.
Earlier quoted context omitted.
Right up there with Slack etcs fake loading messages "Gearing up the dildonator" "Implicating the fairies" "Hogtying George Bush" Dude - just give me a spinner or a progress bar, and if something errors during the load out give me some sort of stack trace or error ID I can use to help
The one I especially hated: "You look nice today" 1. "Nice" is an adjective with nearly zero meaning. 2. Either you have access to my camera outside of calls and are analysing my appearance (WTF) or you're making stuff up. 3. You're making chat software. Stop trying to butter me up.