đŸ Archived View for republic.circumlunar.space âș users âș flexibeast âș gemlog âș 2022-06-23.gmi captured on 2022-07-16 at 13:46:24. Gemini links have been rewritten to link to archived content
âĄïž Next capture (2023-01-29)
-=-=-=-=-=-=-
There's no shortage of dire error messages produced by software. There's an old joke referencing Ken Thompson[a], one of the creators of Unix, as well as the creator of the programming language âBâ (the predecessor to âCâ) and the video game âSpace Travelâ:
Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the other numerous idiot lights which plague the modern driver. Rather, if the driver makes a mistake, a giant â?â lights up in the center of the dashboard. âThe experienced driver,â says Thompson, âwill usually know whatâs wrong.â[b]
-- https://news.ycombinator.com/item?id=7727206
Recently a Rust dev, new to (Doom) Emacs, reported getting the error:
eldoc error: (user-error No such directory: /usr/local/src/rust/src. Please set 'racer-rust-src-path' or 'RUST_SRC_PATH'.
and asked "Why am I seeing this error, and how can I solve it?"
i couldn't really comprehend how a dev, even a new dev, could ask these questions. Even given the dev being understandably unaware of what âeldocâ is[c], doesn't the error message make it explicit what the problem is, and what needs to be done to fix it? Something was looking for the directory â/usr/local/src/rust/src/â, but that directory doesn't exist. So either the âracer-rust-src-pathâ variable (in Emacs) needs to be set, or the âRUST_SRC_PATHâ environment variable needs to be set. How does the error message not convey this?
It would have totally made sense to me if the dev had instead asked one or more of:
But no, the dev was apparently treating the error message provided by Emacs like it's an inscrutable Guru Meditation[d] providing no actionable information.
i'm an advocate of trying to make error messages as helpful to the dev or user as possible. It's both sad and irritating that i _still_ have to occasionally resort to e.g. using strace(1) to examine a program's calls of open(2) because that program has failed with the error message:
Couldn't open file
For crying out loud, if your code tries to open a file, and it fails, don't just report to the dev or user that a file couldn't be opened! Describe _which_ file couldn't be opened, and pass on any information provided by the relevant system call regarding the reason for the failure, e.g.:
Couldn't open /some/config/file: Permission denied
That said, surely there's a point at which one can say: âI've provided the dev/user with all the information they need to fix the issue, but they seem to be ignoring it; more work here has an opportunity cost I'm not willing to payâ?[e]
--
đ· dev,ict
--
[a] Wikipedia: âKen Thompsonâ
[b] This is a reference to ed(1), the text editor that Ken Thompson developed for Unix: ed's approach to error reporting is to simply print â?â (and nothing else). The glibc library includes an error macro âEDâ:
â?.â The experienced user will know what is wrong.
âThe GNU C Libraryâ / âError codesâ / âEDâ
[c] It's an Emacs system for showing the documentation for a particular identifier (e.g. a function) in Emacs' echo area.
[d] Wikipedia: âGuru Meditationâ
[e] Having moved to Gentoo in the last year, i've been impressed by both the quality of error messages provided by e.g. emerge(1), and by how many users seek help with fixing an issue when the system has _literally told them exactly what they need to do_.