An application can use any combination of the error properties for its own error handling. For example, an application might have a specialized module for handling error states. When such a state is detected, the error code could be passed to the error-handling module and used in a decision branch construct to take a special action unique to a given error condition.
To return error messages in a language other than English, specify an appropriate value in the ErrorLanguage field of the request.
To check whether you have accidentally misspelled a field name, passed in a field that does not exist, or if you are using deprecated input fields, set WarningLevel to a value of High. It is recommended that this be used only for testing and debugging purposes and not in a production application.
Refer to the following table for information about the three error messages that are associated with WarningLevel:
| Error Code | Long Error Message | Meaning |
|---|---|---|
| 21927 | The element {0} was found in the input SOAP request. This is not a declared element in the schema and will be ignored. | This means you have specified an element that we don't recognize. (This could occur if you spell the element name differently than we do, or if you send it in the wrong node.) |
| 219450 | The input object "{0}" is deprecated as of schema version {1}. Replacement: "{2}". | This means the object is deprecated as of the specified schema version, and we will stop supporting it for all versions in the future. |
| 219451 | The input object {0} is no longer supported and will be ignored. | This means we no longer support the object for any schema version. |
Refer to Errors by Number for the current list of all possible error codes and messages that can be returned.
SDK considerations
When using the SDKs, errors come from two sources:
-
API errors are raised by eBay. For additional information, refer to:
-
Errors also are raised that are Java or .NET application errors, or errors that might occur as a result of attempting to use SDK classes.
These errors need to be handled in different ways.
To handle Java or .NET errors, enclose important and volatile operations (such as creating an object and accessing its methods) in a try..catch construct.
If you are using the SDKs, API errors will not trigger an exception that will be captured by a try..catch construct. Rather, the API call object's execution method would be processed normally, but instead of a result set consisting of data there will be an error construct returned (or data and a warning type error construct in the case of warnings). An API error of this sort typically occurs due to bad or invalid data being supplied as input or by a required value not being supplied. For example, if AddItemCall is used to list an item and no starting price is specified, an API error would result.
If you are using the SDKs, determine if there are any API errors or warnings after a call by calling the hasError( ) and the hasWarning( ) methods of the API call class (AddItemCall, GetSellerListCall, etc.). The hasError( ) method returns a value of true if any API exceptions resulted from the call. In this case, get the call object's exception object using the getApiException( ) method and inspect the exceptions it contains to determine what went wrong. If an API exception occurs, the call results in the return of just an error and no data is returned. The hasWarning( ) method returns a value of true if a warning was returned as a result of the call. Visit the ApiException property of the call object to retrieve the warning. When warnings occur, the call will have been processed normally (such as the listing of an item) and the call returns the normal result set. It is just that the normal result set is also accompanied by the warning.