Can you please explain this? That sounds like identifying bugs but not fixing them but I realize you don’t mean that. One hopes the context information in the error will make it actionable when it occurs, never completely successfully, of course.

▲

rwmj a day ago | parent | next [-]

Here's an example of a bug that I filed about non-actionable error messages: https://github.com/karmab/kcli/issues/456

The first error message was "No usable public key found, which is required for the deployment" which doesn't tell me what I have to do to correct the problem. Nothing about even where it's looking for keys, what is supposed to create the key or how I am supposed to create the key.

There are other examples and discussion of what they should say in the link.

Edit: Here's another one that I filed: https://github.com/containers/podman/issues/20775

	▲	1123581321 a day ago \| parent [-]
		That makes sense and good examples; thanks. At work, I can think of cases where we error when data mismatches between two systems. It’s almost always the fault of system B but we present the mismatch error neutrally. Experienced developers just know to fix B but we shouldn’t rely on that.

▲

Copenjin a day ago | parent | prev [-]

You can hope that the person reading the context will always able to understand it like you would have. Bad assumption in my experience.

	▲	1123581321 a day ago \| parent [-]
		Quite true. It can be a bad assumption when I’m the one trying to understand it weeks later. :)