Package google.rpc
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Estado
El tipo de Status define un modelo de error lógico que es adecuado para entornos de programación diferentes, incluidas las API de REST y las API de RPC. Lo usa gRPC. El modelo de errores está diseñado para ser de la siguiente forma:
- Fácil de usar y entender para la mayoría de los usuarios
- Lo suficientemente flexible para satisfacer necesidades inesperadas
Descripción general
El mensaje Status contiene tres datos: código de error, mensaje de error y detalles del error. El código de error debe ser un valor de enumeración de google.rpc.Code, pero puede aceptar códigos de error adicionales si es necesario. El mensaje de error debe ser un mensaje en inglés dirigido al desarrollador que ayude a los desarrolladores a understand y understand el error. Si se necesita un mensaje de error localizado orientado al usuario, coloca el mensaje localizado en los detalles del error o localízalo en el cliente. Los detalles opcionales del error pueden contener información arbitraria sobre el error. Hay un conjunto predefinido de tipos de detalles del error en el paquete google.rpc que puede usarse para condiciones de error comunes.
Asignación de idiomas
El mensaje Status es la representación lógica del modelo de errores, pero no es necesariamente el formato de conexión real. Cuando el mensaje Status se expone en diferentes bibliotecas cliente y diferentes protocolos de conexión, puede asignarse de manera diferente. Por ejemplo, probablemente se asignará a algunas excepciones en Java, pero es más probable que se asigne a algunos códigos de error en C.
Otros usos
El modelo de error y el mensaje Status pueden usarse en una variedad de entornos, con o sin API, para proporcionar una experiencia de desarrollador consistente en diferentes entornos.
Los ejemplos de usos de este modelo de error incluyen lo siguiente:
Errores parciales. Si el servicio debe mostrar errores parciales al cliente, puede incorporar Status en la respuesta normal para indicar los errores parciales.
Errores de flujo de trabajo. Un flujo de trabajo típico tiene varios pasos. Cada paso puede tener un mensaje Status para los informes de errores.
Operaciones por lotes. Si un cliente usa una solicitud por lotes y una respuesta por lotes, el mensaje Status debe usarse directamente dentro de la respuesta por lotes y debe haber uno para cada respuesta secundaria de error.
Operaciones asíncronas. Si una llamada a la API incorpora los resultados de la operación asíncrona en su respuesta, el estado de esas operaciones debe representarse directamente mediante el uso del mensaje Status.
Registros. Si algunos errores de la API se almacenan en los registros, el mensaje Status podría usarse directamente después de cualquier eliminación necesaria por motivos de seguridad o privacidad.
| Campos |
code |
int32
El código de estado, que debe ser un valor enum de google.rpc.Code.
|
message |
string
Un mensaje de error dirigido al desarrollador, que debe estar en inglés. Cualquier mensaje de error dirigido al usuario debe localizarse y enviarse al campo google.rpc.Status.details; o el cliente debe localizarlo.
|
details[] |
Any
Una lista de mensajes que contienen los detalles del error. Hay un conjunto común de tipos de mensajes para que usen las API.
|
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-07-26 (UTC)
[null,null,["Última actualización: 2025-07-26 (UTC)"],[[["\u003cp\u003eThe \u003ccode\u003eStatus\u003c/code\u003e type defines a consistent and flexible error model suitable for various programming environments, including REST APIs and RPC APIs.\u003c/p\u003e\n"],["\u003cp\u003eIt provides three key pieces of information: an error code using \u003ccode\u003egoogle.rpc.Code\u003c/code\u003e, a developer-facing English error message, and optional error details for context.\u003c/p\u003e\n"],["\u003cp\u003eWhile logically represented by the \u003ccode\u003eStatus\u003c/code\u003e message, its actual implementation may vary across languages and wire protocols.\u003c/p\u003e\n"],["\u003cp\u003eThis error model can be utilized in diverse scenarios beyond APIs to ensure a uniform developer experience, including partial errors, workflow errors, batch operations, and asynchronous operations.\u003c/p\u003e\n"]]],["The `Status` message defines an error model with three data pieces: `code`, `message`, and `details`. The `code` is an error code, `message` is a developer-facing English error message, and `details` contains additional error information. This model can be used for partial, workflow, batch, and asynchronous operations and in logging. It is designed for simplicity and flexibility and is adaptable across different programming environments and API types, with a mapping system that can change based on implementation.\n"],null,["# Package google.rpc\n\nIndex\n-----\n\n- [Status](/assistant/sdk/reference/rpc/google.rpc#google.rpc.Status) (message)\n\nStatus\n------\n\nThe `Status` type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by [gRPC](https://github.com/grpc). The error model is designed to be:\n\n- Simple to use and understand for most users\n- Flexible enough to meet unexpected needs\n\n#### Overview\n\nThe `Status` message contains three pieces of data: error code, error message, and error details. The error code should be an enum value of `google.rpc.Code`, but it may accept additional error codes if needed. The error message should be a developer-facing English message that helps developers *understand* and *resolve* the error. If a localized user-facing error message is needed, put the localized message in the error details or localize it in the client. The optional error details may contain arbitrary information about the error. There is a predefined set of error detail types in the package `google.rpc` that can be used for common error conditions.\n\n#### Language mapping\n\nThe `Status` message is the logical representation of the error model, but it is not necessarily the actual wire format. When the `Status` message is exposed in different client libraries and different wire protocols, it can be mapped differently. For example, it will likely be mapped to some exceptions in Java, but more likely mapped to some error codes in C.\n\n#### Other uses\n\nThe error model and the `Status` message can be used in a variety of environments, either with or without APIs, to provide a consistent developer experience across different environments.\n\nExample uses of this error model include:\n\n- Partial errors. If a service needs to return partial errors to the client, it may embed the `Status` in the normal response to indicate the partial errors.\n\n- Workflow errors. A typical workflow has multiple steps. Each step may have a `Status` message for error reporting.\n\n- Batch operations. If a client uses batch request and batch response, the `Status` message should be used directly inside batch response, one for each error sub-response.\n\n- Asynchronous operations. If an API call embeds asynchronous operation results in its response, the status of those operations should be represented directly using the `Status` message.\n\n- Logging. If some API errors are stored in logs, the message `Status` could be used directly after any stripping needed for security/privacy reasons.\n\n| Fields ||\n|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `code` | `int32` The status code, which should be an enum value of `google.rpc.Code`. |\n| `message` | `string` A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details](/assistant/sdk/reference/rpc/google.rpc#google.rpc.Status.FIELDS.repeated.google.protobuf.Any.google.rpc.Status.details) field, or localized by the client. |\n| `details[]` | [Any](https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#google.protobuf.Any) A list of messages that carry the error details. There is a common set of message types for APIs to use. |"]]
