Removing function names from errors (PR 9058)

[Matt Caswell]

I agree with everything Richard just said. I just have some additional thoughts
inserted below.

On 13/06/2019 10:00, Richard Levitte wrote:
> If we look at it from the perspective of the application author,
> what's most often needed are reliable error/reason codes (to check and
> to react appropriatly to) and associated reason strings (for display).
> For the application author, it would normally be completely
> uninteresting exactly which function the error happened in (think
> about it, when's the last time you wanted to know exactly which
> internal function in libc raised the EAGAIN you just got?).  For the
> application author, the interesting bit is usually "what went wrong?"
> (reason) and "what did I call?" (they already know that).
> 
> 
> If we look at *our* needs as library writers, then the exact location
> that raised the error is interesting, of course!  But then, is it
> interesting in the form of codes, or are we rather interested in the
> text form?  I dunno about you, but I don't give a damn about the
> actual library and function codes, I look at the displayed library
> names and function names.  (and yet, they aren't necessarily enough
> without knowing the OpenSSL version).
> 
> 
> Finally, if we look at it from a provider author's perspective,
> dealing with all these different codes is quite hard.  Ideally, a
> provider author should just need to deal with their own reason codes
> and associated strings, and that's about it.

I think you missed another important perspective, i.e. that of the end user.

Note that this is slightly different to the needs of the application author. An
application author will typically do one of two things if an error occurs:

1) Try and figure out the cause of the error and recover from it, e.g. if I get
reason code x then I'll retry the operation with slightly different parameters
but if I get y then I'll just ignore this failure and carry on anyway.

or

2) If its an error they don't know how to handle then give up and display
whatever error details are available to the end user (or log them, or whatever)

So the application author is going to want a small number of reason codes that
they can handle. If its not in the small set they know about, then give up.

The end user OTOH doesn't care about reason codes at all and wants as detailed
an explanation of the error (in text form) as is possible. Potentially that
might mean different text for every point in the code where we raise an error.
Ideally they might want information about the context that led up to the error,
i.e. what particular operation was being attempted at the time. I'm thinking
that there is some relationship here between the information available from the
trace API, and the error API.


> What I would like to see is a simplified error system that delivers
> reason codes, and attached extra text information.  That text
> information could have two parts, where one is debugging information
> (__FILE__, __LINE__, __FUNC__, and possibly exact commit hash
> generated with 'git archive', see "export-subst" in gitattributes(5)),
> and the other is the extra data added with the likes of
> ERR_add_error_data().
> We certainly already have the infrastructure to allow this, the
> modifications needed wouldn't be that big.

+1 to this.

Matt