I read either someone's blog, or social media post, or reply, or something that talked about error messages. Specifically, about being able to recognize the error messages you wrote, instead of ones returned by the library you using, or by the language itself. I can't find it. Every search leads to the basic "how to write code that returns an error", and a little bit of "what are good practices for error messages", but nothing specifically about "what are some ways I can make my error messages different enough from the error messages returned by everything else".

I'm sorry, what niche use-case/rabbit-hole are you in, where this isn't a pointless exercise?

Because the #1 best-kept not-so-secret about people in the software space is that we Google¹. A lot. Very often, the first instinct is to highlight the error message, hit Ctrl-C, reach for the browser, Ctrl-V, and scroll and click to your heart's desire. But when you've seen so many different error messages across so many different contexts, some of which mean the same thing just in different words, they all start to look the same. Then you spend an hour dredging through GitHub issues, wiki pages, forum posts, finding logs that are close but aren't really the same as what you're looking for. After another hour, you finally decide to grep the whole folder and see what pops up and there it is. It's one of yours. That's your kid, grinning ear-to-ear with mud all over their boots and the hardwood downstairs because you decided in the moment to start writing good error messages that look so professional and nice and neat.

...I've got a few layers of abstraction:

  graph TD
    A(User-facing code)
    B(Library code I wrote)
    C(External libraries)
    D(The language)

    A --> B --> C --> D
    B --> D

That second one is mainly what we're focused on, with a little bit of the first. It's obviously important to error handle gracefully, and especially here where we're the go-between of someone else's code could go wrong and our code could go wrong. We're using a mix of external libraries that have their own errors and the standard library with their own errors. We take any errors given to us, prepend a little message as a nudge to say "here, search locally for this!", and pass it up. Now how do we make sure that nudge is future-proofed, that a future us who's since lost all mental context can see it and go, "oh, that's my kid"?

• use specific language, in the front, or at the end of the message (e.g. I like to put an aesthetically pleasing DEBUGGING: ... when I do "debug by print statements"),
• use textual markers or color, like wrapping your message in exclamation points or putting ANSI-sequences in your output to make your message puke yellow foreground and purple monster background (actually, that's not half bad),

and that's where I ran out of ideas² and needed some inspiration from that particular piece of reading material I could never find. In the end, this becomes a question of developing your own style, or even setting a standard for the larger group you're working in. Yeah granted, if every library and language and company did their own, we'd end up with 15 competing eye-catching things in our logs and that's not a good look.

Me? I debated prepending a <> (angle brackets) to each message, but after some time, I felt that warm blanket of satisfaction fall over me when I finally settled on:

- could not read/write file: {}
+ could not read/write file, fool: {}
...
- could not insert pair into database: {}
+ could not insert pair into database, fool: {}