title: Handling (possibly-changing) error codes of a library using exceptions
body: <p>Let's say you are using a library that returns error codes. You'd like to write a wrapper for the library, and you'd like to handle errors with exceptions in the code.</p>
  
  <p>If the library is still in development by someone else, and if the error codes may change (there can be new ones, there can be deprecated ones, or some error codes may change meaning slightly), what would your solution be to handle this?</p>
  
  <p>This is the situation that I'm in right now. In my case, the library is written in C++, and we're using C#. The coder of the library says the error codes may change, and I have to find a way to work with it.</p>
  
  <p>Our initial solution is to:</p>
  
  <ol>
  <li>Create an XML file that has the error codes in different categories (terminal ones, input errors, and so on).</li>
  <li>Wrapper fetches these error codes on start.</li>
  <li>Throws the appropriate exception by checking the category of the error code.</li>
  </ol>
  
  <p>So let's say a method returns error code 100, then the wrapper checks the category of the error code. If it is a <em>terminal error</em> it throws a <em>terminal error exception</em>, if it is a <em>user input error</em> it throws a <em>user input error exception</em>.</p>
  
  <p>This should work, but I feel like this is not the optimal solution. I'd like to know how good written enterprise software handle change of error codes.</p>
  
  <p>What would you suggest doing?</p>
  
  <p><strong>Edit:</strong> I have already questioned the fact that error codes will be changing and the coder of the library says the code is in development. It's an algorithm, so even the way the algorithm works changes as it's original research (he's writing his PhD on that). So he says there may be different errors, or some may be irrelevant in the future.</p>