Error/Exception
GS2 responds to errors according to certain rules. By understanding these rules, you will be able to resolve errors quickly.
Example of an error message
[{"component": "progress", "message": "quest.progress.progress.error.notFound"}]
| section | description |
|---|---|
| component | Indicates the target where the error occurred, and contains the member name and method name. |
| message | Details of the error location and keywords that describe the error. serviceName.component.error.errorType |
Major error types
| major error content | description |
|---|---|
| failed | Processing failed. |
| invalid | Illegal parameter. |
| require | Missing required argument. |
| tooLong | Argument is too long. |
| tooMany | Too many array elements. |
| exists | Already exists. |
| duplicate | duplicate, already exists. |
| notFound | Not found. |
| notMatch | No match was found. |
Types of Exceptions
Errors are classified to some extent by SDK, and the type of exception sent out varies.
| Exception | Error Content | Status Code | Retry recommended |
|---|---|---|---|
| BadRequestException | Bad request content. | 400 | |
| UnauthorizedException | Could not authenticate the authorization required to connect to GS2; also raised if the access token used for API access has expired. | 401 | |
| QuotaLimitExceededException | Quota (allocation) limit exceeded. | 402 | ✔ |
| NotFoundException | The object of the request could not be found. | 404 | |
| ConflictException | Processing conflict. | 409 | ✔ |
| InternalServerErrorException | An error occurred on the server. | 500 | ✔ |
| BadGatewayException | The server received an invalid response. This error occurs when a connection with another server or GS2 microservice fails. | 502 | ✔ |
| ServiceUnavailableException | An error occurred in the service. | 503 | ✔ |
| RequestTimeoutException | Request timed out. | 504 | ✔ |
| UnknownException | Unknown exception occurred. | 505 | ✔ |
Exceptions marked “Retry recommended” are errors that may occur due to server conditions, although the request parameters are normal. When such errors are detected, it is recommended to retry.
It is strongly recommended to implement a timeout after a certain number of times or a certain amount of time, rather than retrying until success. When retrying, it is recommended that a sleep be inserted between requests, and that the length of the sleep be increased according to the number of retries.
For errors that require in-game handling, some microservices define error-specific exception types that inherit from the exceptions enumerated for each microservice. In such cases, error handling can be more easily implemented by using error-specific exceptions. If there are exceptions that represent error-specific errors, please refer to the method descriptions in the API reference.