Removing function names from errors (PR 9058)

Tim Hudson tjh at
Thu Jun 13 09:34:59 UTC 2019

On Thu, Jun 13, 2019 at 6:40 PM Salz, Rich <rsalz at> wrote:

> The proper way to handle this, in my experience, is *DO NOT REUSE ERROR

No. This is a path to a rather unacceptable outcome.
Taking your example and running forward with it, having an out-of-memory
separate error code for every possible context would like to *589 error
codes* for just handling out-of-memory in master at a single level.
And then on top of that you would need to cascade those errors up the call
chain potentially.

Each error condition that might require different treatment should have a
common code.
The concept of out-of-memory (as a simple example) is not context specific
(in terms of handling).
The concept of unable-to-open-file is also not context specific.

What the current error system does is to provide a context for the user
when error conditions occur to be able to have some idea as to what
It is very much like the java stack trace - and useful for a variety of

The error system had two purposes:
1) allow for handling of an error by the calling function (or any function
up the call stack) in a different manner
2) provide the end user with context when things fail (as applications are
generally not very good at doing this)

Both of these are equally important - but aimed at different contexts
(developers, end-users).
Neither context should be ignored when considering changes IMHO.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openssl-project mailing list