Patrick Steinhardt <ps@xxxxxx> writes: > This parameter would only exist for the purpose of the error message, > right? If so, I think that'd be overkill. If we want to have differing > errors depending on how the function is called the best way to handle > that would likely be to generate the error message at the callsite > instead of in the library itself. We would need to make sure the lower-level helpers need to be able to tell what kind of failure they saw (in other words, why they are failing) to the callers, which may require a bit of designing the error return convention and plumbing through necessary pieces of information, but the longer term payoff would be great. I do not think this is such a case, but if the lower-level needs to fail differently (e.g., the thing not existing is acceptable when writing as we will create a new one, but is a fail-worthy error when reading), then the caller needs to give that down the callchain, though.
