Package google.rpc
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Stan
Typ Status definiuje model błędu logicznego, który jest odpowiedni dla różnych środowisk programowania, w tym interfejsów API REST i interfejsów API RPC. Jest używany przez gRPC. Oto model błędu:
- Proste w obsłudze i zrozumiałe dla większości użytkowników
- Elastyczność, która zaspokaja nieoczekiwane potrzeby
Opis
Komunikat Status zawiera 3 rodzaje danych: kod błędu, komunikat o błędzie i szczegóły błędu. Kod błędu powinien być wartością wyliczeniową google.rpc.Code, ale w razie potrzeby może akceptować dodatkowe kody błędów. Komunikat o błędzie powinien być przeznaczony dla programistów w języku angielskim i ułatwiać im understand i understand błędu. Jeśli potrzebny jest zlokalizowany komunikat o błędzie, który wyświetla się użytkownikowi, umieść go w szczegółach błędu lub zlokalizuj go w kliencie. Opcjonalne szczegóły błędu mogą zawierać dowolne informacje o błędzie. W pakiecie google.rpc istnieje wstępnie zdefiniowany zestaw typów szczegółów błędów, których można używać w przypadku typowych błędów.
Mapowanie języka
Komunikat Status jest logiczną reprezentacją modelu błędu, ale niekoniecznie jest to rzeczywisty format przewodu. Gdy komunikat Status jest ujawniany w różnych bibliotekach klienta i różnych protokołach przewodów, można go zmapować na różne sposoby. Na przykład prawdopodobnie zostanie ona zmapowana na pewne wyjątki w Javie, ale prawdopodobnie będzie zmapowana na pewne kody błędów w języku C.
Inne zastosowania
Modelu błędu i komunikatu Status można używać w różnych środowiskach – z interfejsami API lub bez nich, aby zapewnić spójne wrażenia programistyczne w różnych środowiskach.
Przykładowe zastosowania tego modelu błędów:
Błędy częściowe. Jeśli usługa musi zwracać klientowi częściowe błędy, może umieścić element Status w normalnej odpowiedzi, aby wskazać te błędy.
Błędy przepływu pracy. Typowy przepływ pracy ma wiele etapów. W każdym kroku może pojawić się komunikat Status służący do zgłaszania błędów.
Operacje wsadowe. Jeśli klient korzysta z żądania zbiorczego i odpowiedzi zbiorczej, komunikat Status powinien zostać użyty bezpośrednio w odpowiedzi zbiorczej – po jednym dla każdego błędu podrzędnego.
Operacje asynchroniczne. Jeśli wywołanie interfejsu API powoduje umieszczenie asynchronicznej operacji w wyniku uzyskania odpowiedzi, stan tych operacji powinien być reprezentowany bezpośrednio za pomocą komunikatu Status.
Logowanie. Jeśli niektóre błędy interfejsu API są przechowywane w dziennikach, komunikat Status może zostać użyty bezpośrednio po usunięciu niektórych błędów ze względów bezpieczeństwa lub prywatności.
| Pola |
code |
int32
Kod stanu, który powinien być wartością wyliczeniową google.rpc.Code.
|
message |
string
Komunikat o błędzie widoczny dla dewelopera w języku angielskim. Każdy komunikat o błędzie widoczny dla użytkownika powinien być zlokalizowany i wysyłany w polu google.rpc.Status.details lub zlokalizowany przez klienta.
|
details[] |
Any
Lista komunikatów zawierających szczegółowe informacje o błędzie. Istnieje wspólny zestaw typów wiadomości używanych przez interfejsy API.
|
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-26 UTC.
[null,null,["Ostatnia aktualizacja: 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. |"]]
