One of the least-appreciated skills in programming is writing anti-frustrating error messages. A good error message should make it self-evident (a) what the user did, (b) what acceptable inputs are, and (c) how to fix the problem. Can determine love or hate for your library.

Feb 22, 2022 · 4:24 PM UTC

245
663
50
8,979
Replying to @gdb
*Wild Windows appears*: Task failed successfuly, error code 000000x, google: generic Windows error, cause: anything ranging from motherboard implosion to thursday. "Windows troubleshooter did not indentified the error"
2
17
Replying to @gdb
💯
215
102
10
3,799
Replying to @gdb
if only this was a widely accepted practice
2
Replying to @gdb
expected int received string. Perfection
2
Replying to @gdb
Yes yes yes!!!
Replying to @gdb
But ser muh gas costs
Replying to @gdb
this is something that no company gets right, only artists
Replying to @gdb
Error handling is an art and deserves full attention. A good error message contains 3 parts: (1) error name (2) error description (3) suggested action The description will not only explain the error, but include likely causes. Optional (4): links to stack overflow posts
1
Replying to @gdb
Exception messages are documentation and documentation is the thing developers like to do least. I tried, for a while, 'Documentation Driven Development', where you avoid coding, adding more and more detailed documentation, until only code can capture the remaining detail.