<div dir="ltr"><div dir="ltr">On Thu, Jun 13, 2019 at 6:40 PM Salz, Rich <<a href="mailto:rsalz@akamai.com">rsalz@akamai.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The proper way to handle this, in my experience, is *DO NOT REUSE ERROR CODES.* </blockquote><div><br></div><div>No. This is a path to a rather unacceptable outcome. </div><div>Taking your example and running forward with it, having an out-of-memory separate error code for every possible context would like to <b>589 error codes</b> for just handling out-of-memory in master at a single level.</div><div>And then on top of that you would need to cascade those errors up the call chain potentially.</div><div><br></div><div>Each error condition that might require different treatment should have a common code.</div><div>The concept of out-of-memory (as a simple example) is not context specific (in terms of handling).</div><div>The concept of unable-to-open-file is also not context specific.</div><div><br></div><div>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.</div><div>It is very much like the java stack trace - and useful for a variety of reasons. </div><div><br></div><div>The error system had two purposes:</div><div>1) allow for handling of an error by the calling function (or any function up the call stack) in a different manner </div><div>2) provide the end user with context when things fail (as applications are generally not very good at doing this)</div><div><br></div><div>Both of these are equally important - but aimed at different contexts (developers, end-users). </div><div>Neither context should be ignored when considering changes IMHO.</div><div><br></div><div>Tim.<br></div><div><br></div></div></div>