Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When you write wrappers for APIs how do you handle usage errors?

Do you assume that the user uses it right and write the wrapper such that it makes the call to the server and let the server return the error?

Or do you check for the missing parameters and return an error? If yes, how do you convey the error? a string or an error code?

share|improve this question
Typically a function should do its own validation for things it is responsible for. If it calls other functions then its validation should be done by those functions. – MNS May 18 '15 at 5:05

Think wrapper vs adapter vs bridge from a design pattern point of view. You might have a new perspective and find your answer from there.

E.g. Adapters and Wrappers from Andy Kramek and lots more if you google.

share|improve this answer

A lot of the answer depends on the API you're wrapping, the target audience for wrapping it and the language you're using. If you're exposing an API written in one particular technology to a different technology, there'd be value in smoothing out some of the common problems in the wrapped technology. For example, .NET wraps up some Win32 APIs, like CreateFile() to read a file. It's quite easy to use the wrong parameters for CreateFile(), so if you want to do something simple like read a text file, there's a utility function to achieve just that operation, rather than just encapsulating each function with a wrapped version.

Checking the input parameters for empty/null/out-of-range before calling the wrapped API would have value, but not if its at the expense of performance - better to decipher the problem when the wrapped function fails.

Exceptions, if available in your wrapping language, would be appropriate for conveying errors to the caller.

share|improve this answer

You should never trust your caller, who is calling your API. You need to implement tight checks on the inputs. And always validate the request object before sending it to further processing. You can use the approach of giving a response object to the caller. Having a field of response code and response description. And you can standardized these response codes for your application.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.