On Thu, Jun 13, 2019 at 6:40 PM Salz, Rich <rs...@akamai.com> wrote: > The proper way to handle this, in my experience, is *DO NOT REUSE ERROR > CODES.*
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 happened. It is very much like the java stack trace - and useful for a variety of reasons. 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. Tim.
