What is it you are actually warning me of?

That it is mostly LLM words which some of us here don't really like to read as it can be low entropy in language, structure, ideas.

Speaking of which, why aren't the LLMs solving these low level plumbing problems for us yet?

Because LLMs mostly follow historical practice. And examples for bad error handling are more common (and easier) than good error handling.

I'm pretty sure an LLM will be able to handle an instruction such as:

"Wherever exceptions are thrown, add as much contextual information to the exceptions as possible. Use class RichException<Exception> to store the extra information". Etc. etc.

Sure, but writing and maintaining such instructions is also work. And not something one thinks about usually until the debugging session with insufficient errors.

Yeah. Certainly felt like that. On the other hand, the content does seem good. It definitely wasn't slop, even if I can't judge how useful it really was (in terms of giving a solution).

This is the pull request of this post: https://github.com/fast/fast.github.io/pull/12

See comments like https://github.com/fast/fast.github.io/pull/12#discussion_r2...

Quote my comment in the other thread:

> That said, exn benefits something from anyhow: https://github.com/fast/exn/pull/18, and we feed back our practices to error-stack where we come from: https://github.com/hashintel/hash/issues/667#issuecomment-33...

> While I have my opinions on existing crates, I believe we can share experiences and finally converge on a common good solution, no matter who made it.