Design pattern for handling a lot of error codes

Project I'm currently working on must work with web API which returns a lot of error codes in number format.

For example, if I have an error "ACCESS_DENY" it may have different meaning depended on context where it has been used. For every error I must show an alert message. In this way alert message also can be different for different situations in spite of error code is the same. It can't be changed because it's a problem of the API.

But the problem is that API continuously is being changed. I don't want to edit my code all the time. Moreover, I'm not consider to write exception class for every category of error. Probably, one of the solution is to put all errors in XML file and write a singleton for work with it. But it seems for me not very clear decision.

I'm writing an iOS project using Objective-C language and iOS SDK.

What's the good aproach to solve this problem?

I think the best approach is to practice "contract-first" development. Prepare:

• Use-case specific payload-in/out objects.
• Reusable domain objects.
• Map the results of your service requests/responses from the use-case specific payload objects onto your reusable domain. . . this way if it changes you need only change the mapping layer.
• Practice the tenet "be strict in what you do, be lenient in what you accept from others" aka "don't spill your guts". . . actually its more appropriate for the service producer to adhere to this than the clients. . .

The idea is that you present an API that is relatively stable over time, but are free to change what happens behind the API. If the API changes consider all of the service-subscribers that will change too. Avoid big-upfront-design, but try to get the integration contract fleshed out ASAP.