Live data from Hacker News

Write better error messages

wix-ux.com

261–265 of 265 posts

Re: Write better error messages

#261

Earlier quoted context omitted.

If it is that simple, the why doesn't the code fix it itself? But no, usually there is 1/2/3 likely things, but it also could be anything else.. and that kind if unexpected errors even often have no default-fix. No, the most best thing is to point to the documentation which has that, and not printig out manpages of docs in error messages now. > I write software that is generally run low in the stack What stack, how l…

In the case at hand, where an environment variable isn't set, how exactly should the code fix itself? Human interaction is necessary, which is the reason the log message should spell out what the human needs to do. If I'm starting a service and see a pointer in the logs to documentation, that seems like an incredibly broken approach to me. Why would I look at missing or out-of-date documentation that may or may not b…

Similar issues arises with such documentation in error messages. There now has to be a process to make sure that all such information is always accounted for and updated correspondingly when the system changes.

> Something went wrong, but I don't want to tell you what.

is somewhat disingenius of an example. Error logs should tell in exhausting detail what went wrong. Ops needs that to analyse the situation, and the vendor will have much less trouble reproducing the error. However, suggesting specific fixes could be disastrous. Furthermore, documentation should already be in a form that operations can be expected to work with also in crisis situations.

Re: Write better error messages

#262
post #7

There are fundamentally two classes of error message: 1. Information that can help a technically engaged person debug a problem. 2. Information that can help a user of the system understand what they have to do the overcome the problem. Since most error messages are created by people responsible for debugging the system they tend to be of the 1st class. There has to be a way to provide different information based on…

There's a fatal flaw in assuming that there's no overlap between groups 1 and 2.

[deleted]

Re: Write better error messages

#263

Earlier quoted context omitted.

It terminates the program with panic! https://doc.rust-lang.org/std/macro.unreachable.html

So is the usual flow to throw these in places where code shouldn't execute but then create tests to try and trip it up to see if that is truly the case? I would hate to be running a release build with this, or does the compiler do something different depending on build type?

> I would hate to be running a release build with this

The usual argument is that the program would be in an invalid state if the condition was reached, so the only option is to crash. If it turns out it's a valid state, then the programmer can treat in a branch. I don't think tests would capture this because they would operating under the same assumption that such states cannot exist. Maybe fuzzy testing could surface an issue like this.

Re: Write better error messages

#264

Probably just me, but I am less concerned with how good my error messages are, and more concerned with trying very very hard to make the errors happen closer to the cause of the problem, rather than further away. "Fail early, fail hard" i.e. if I can make the error message happen near the beginning of a process, I can get away with making it a hard error. Hard errors in the middle of a multi-hour operation tend to an…

That's not really a respectful practice. Error messages should be clear and actionable. Users don't care if you consider an error soft or hard.

Fail Fast means your logging infrastructure is going to report to you more quickly to get the problem fixed.

As opposed to 6 months down the road when someone finally notices an uptick in complaints by customers and now the potential problem sites is literally the entire software stack.

fail fast is how stable software is made, the question is whether or not you think customers appreciate stable software.

Re: Write better error messages

#265

At a previous job, writing unambiguous error messages was discouraged. Everything just had to be "Oops! Something went wrong" The reasoning was that "users can't do anything with information we tell them anyways", despite the overwhelming number of help desk tickets we'd get from "Oops!" appearing in a million different scenarios with no clear way for us to tell what error actually caused the message to appear. Users…

The error user see and the one you log shouldn't be the same, you still can log complete information about an error, while the user will see only "Oops, something went wrong"
Post reply on HN