Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the Fastly outage can teach us about writing error messages

onlineornot.com

Post reply on HN
Print view View original

81–90 of 137 posts

Re: What the Fastly outage can teach us about writing error messages

#81

Post by chakkepolja »

IshKebab wrote: post #78
bullen wrote: post #73

I'm a believer in not hiding things and logging the whole problem all the way to the end consumer: http://test.rupy.se/?id=2 Because when you develop things you are the end consumer.

Also, consumers may not understand backtraces but they generally understand how to Google them or ask other people what they mean, or tell you about them. Technical errors are way better than just "I'm sorry we couldn't process that right now."

This is probably a dumb question, but isn't a backtrace likely to reveal some sensitive information from a security perspective?

Re: What the Fastly outage can teach us about writing error messages

#82

Post by karlerss »

bullen wrote: post #73

I'm a believer in not hiding things and logging the whole problem all the way to the end consumer: http://test.rupy.se/?id=2 Because when you develop things you are the end consumer.

This is considered a critical security vulnerability. [0]

[0] https://owasp.org/www-project-top-ten/2017/A6_2017-Security_...

Re: What the Fastly outage can teach us about writing error messages

#83

Post by denysvitali »

sschueller wrote: post #76
userbinator wrote: post #41

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…

If we keep dumbing down the world for everyone instead of teaching those who don't know we will destroy ourselves. People are not stupid and if we keep assuming it we are doing a disservice to all. No more www, no more protocol in the address bar and apple is selling iMac colors in it's commercials...

... and blending the search eith the address bar.

I spent a good 1 hour to explain the difference to a tech illiterate on why typing "mywebsite.com" was different from typing "mywebsite com" and picking the first result on Google.

I'm not sure he understood, but I really have to admit that this trend of dumbing down things is only make them worse, in a way.

Re: What the Fastly outage can teach us about writing error messages

#84

Post by jfrunyon »

slver wrote: post #62
WatchDog wrote: post #57

Earlier quoted context omitted.

"Service is experiencing increased error rates" - Error rates increased from 0 to 100%

No service has 0% error rate, and 100% errors doesn't even mean much without context (you never receive all possible errors at once).

Error rate = (number of requests which returned an error) / (total number of requests)

You can choose plenty of time periods to satisfy a 0% error rate for most services - somewhere from milliseconds to days or even years.

Re: What the Fastly outage can teach us about writing error messages

#85

Post by vladvasiliu »

hunter2_ wrote: post #69
vladvasiliu wrote: post #58

Earlier quoted context omitted.

You could do a mix of both: give information useful for support (trace id, error code, etc) but don't explicitly say "send an email to support@bigcorp.com / call 01 23 45 67". The people on the tech side who are the CDN's clients will know who and how to call for support and if it's an end-user they'll be able to transmit this info. Bonus points for the tech guys to figure that there's an issue on their end and that…

> What now? Event Viewer. (You already know, but for the benefit of whomever else.) Hiding things here stinks if you don't know there's something to see there.

Well, the problem with the event viewer is that you kinda have to know what you're looking for beforehand.

I rarely use windows, so I don't know the conventions (if there are any), but I remember one case of someone attempting a remote desktop connection that had an error along the lines of what I said: "Cannot connect". I've never found where the logs for the RDP client were. For servers, we dump the logs in Elasticsearch, so a naïve query will at least set me on the right track.

I'm also not a particularly patient person, so the unbearable slowness of the event viewer's search function and the fact that I never know if I'm looking for Thing, Microsoft Thing, Windows Thing, or ThngSvc, I usually give up in frustration.

And, again, had I had an event id or something, the Find in the event viewer might have been more helpful.

Re: What the Fastly outage can teach us about writing error messages

#86

Post by bullen »

karlerss wrote: post #82
bullen wrote: post #73

I'm a believer in not hiding things and logging the whole problem all the way to the end consumer: http://test.rupy.se/?id=2 Because when you develop things you are the end consumer.

This is considered a critical security vulnerability. [0] [0] https://owasp.org/www-project-top-ten/2017/A6_2017-Security_...

Not if it's open-source.

Security by obfuscation is generally not a good option if you can avoid it.

Re: What the Fastly outage can teach us about writing error messages

#88

Post by nonbirithm »

aniforprez wrote: post #10

Reminds me of the quintessential tweet about error messages https://twitter.com/cherrikissu/status/972524442600558594?s=...

I don't mean to sound frustrated, because this is a volunteer open-source project, not VC-backed corporate software, but whenever the Emacs package flycheck reports an error message, I find the fact that it says (paraphrased) "Please include these details when filing your error report. Thanks!" to be a bit condescending.

It's just something about being thanked in advance for an action I did not intend to do that irks me. It implies to me that the reward for doing it has been given to me without my consent, and now I'm obligated to follow up on my part to prove I deserve it. It ultimately makes me less likely to file a bug report, stemming from this unease.

It's a really minor thing, and definitely not worth getting angry over, but for some reason I always remember it whenever a discussion about out-of-touch error messages happens.

Re: What the Fastly outage can teach us about writing error messages

#89

Post by [deleted] »

hvocode wrote: post #3

I've had more than one intern or young engineer that I've had to teach to resist the urge to put witty comments and jokes in project docs, comments, or errors. Especially in error messages or things that can be exposed to users/customers. Even if it's an error you think only the dev team will see, you never know if it will make its way out to audiences you didn't intend. Somehow I doubt people faced with this error m…

[deleted]

Re: What the Fastly outage can teach us about writing error messages

#90

Post by OJFord »

handrous wrote: post #77
calvinmorrison wrote: post #20

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

What's the first instance of joke progress messages? Is it "reticulating splines" from SimCity 2000 (1993)? Difficulty: must be presented to the user as if it were an actual status message during some process that might have real status messages, not as something explicitly fictional—despite occurring in a game, that message in SC2K qualifies.

Ah interesting, I was going to ask the same but thought it was from /earliest I knew of was The Sims (2000).

(Actually I only now learn that they're related in series - always thought they were competitors.)

Post reply on HN