Removing function names from errors (PR 9058)
tjh at cryptsoft.com
Thu Jun 13 09:34:59 UTC 2019
On Thu, Jun 13, 2019 at 6:40 PM Salz, Rich <rsalz at akamai.com> 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
Each error condition that might require different treatment should have a
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
Neither context should be ignored when considering changes IMHO.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-project