Error handling refers to the anticipation, detection, and resolution of programming, application, compilation and communications errors. Errors can occur in syntax or logic or at run-time but they can also be caused by external factors.
Syntax errors are typographical mistakes that creep in during development and are best handled by rigorous proofreading or automated formatting of code and functional testing to detect them, reveal their cause and location in your system and code.
Often called bugs, logic errors occur when executed code does not produce the expected or desired result often during unanticipated scenarios. These are best handled with meticulous unit and regression testing - once detected the process of debugging can be followed to resolution.
Run-time errors take place during the execution of a program and usually happen because of invalid system parameters or excessive load on the server. These errors are often experienced during periods of degraded performance or network issues.
You may encounter a number of errors and it important to anticipate these and handle them so that they do not interrupt critical business processes and can be logged, inspected and resolved.
Network errors are the result of connectivity problems between client and server and return low-level errors like socket or timeout exceptions. For example, a client might time out while trying to read from BankTech's servers, or an API response might never be received because a connection terminates prematurely. Developers should monitor for network errors, and try requests again later.
Content errors are the result of the contents of an API request being invalid and return an HTTP response with a 4xx error code. For example, the API servers might return a 401 if an invalid API key was provided, or a 400 if a required parameter was missing. Developers should monitor for content errors, refer to technical documentation, correct the original request, and try again.
Server errors are the result of a problem with BankTech's servers and return an HTTP response with a 5xx error code. These errors are the most difficult to handle and we work to make them as rare as possible—but developers should be able to handle them when they do arise by minotoring for server errors, checking the status of our servers, recording references or TraceIDs and reporting the issue to us for investigation.
We take errors seriously and every release is passed through our Software Development Lifecycle (SDLC), based on an Agile philosophy and SCRUM methodology; where development releases are deployed in a staging environment for UAT. We manage to catch most issues by conducting functional, unit and regression tests in UAT and before releasing to Pre Production and Production, but this is not foolproof.
Some of the things that you could do to help manage server errors are:
waiting for a response before submitting another request
giving the server a second or two between requests (longer for large batch payloads)
nesting requests as batches using object sets in one call
retrying 500 errors a few seconds later or an hour later
contacting support if your issue is not resolved by retrying
You should log all errors you receive from us so that these can be resolved. 4XX errors will probably be resolvable by inspecting your request payload for issues/errors. Otherwise, you can force a logging of "x-trace-id" in the header of your request so that we can inspect your payload and help you to resolve any issues with malformation or enumeration.