Package google.rpc

Indeks

• Code (wyliczenie)
• Status (komunikat)

Kod

Kanoniczne kody błędów dla interfejsów API gRPC.

Czasami może pojawić się kilka kodów błędu. Usługi powinny zwracać najbardziej szczegółowy kod błędu. Możesz na przykład wybrać kod OUT_OF_RANGE zamiast FAILED_PRECONDITION, jeśli mają zastosowanie oba kody. Podobnie wolisz NOT_FOUND lub ALREADY_EXISTS zamiast FAILED_PRECONDITION.

Wartości w polu enum
OK	To nie jest błąd; zwrócona w przypadku powodzenia. Mapowanie HTTP: 200 OK
CANCELLED	Operacja została anulowana, zwykle przez element wywołujący. Mapowanie HTTP: żądanie zamknięcia klienta 499
UNKNOWN	Nieznany błąd. Ten błąd może na przykład zostać zwrócony, gdy wartość Status otrzymana z innej przestrzeni adresowej należy do przestrzeni błędów, która nie jest znana w tej przestrzeni adresowej. Także błędy zgłaszane przez interfejsy API, które nie zwracają wystarczającej ilości informacji o błędzie, mogą być konwertowane na ten błąd. Mapowanie HTTP: wewnętrzny błąd serwera 500
INVALID_ARGUMENT	Klient podał nieprawidłowy argument. Różni się to od wartości FAILED_PRECONDITION. INVALID_ARGUMENT wskazuje argumenty powodujące problemy niezależnie od stanu systemu (np. niewłaściwa nazwa pliku). Mapowanie HTTP: 400 Nieprawidłowe żądanie
DEADLINE_EXCEEDED	Termin minął przed ukończeniem operacji. W przypadku operacji, które zmieniają stan systemu, ten błąd może zostać zwrócony nawet wówczas, gdy operacja zakończyła się pomyślnie. Na przykład pomyślna odpowiedź z serwera mogła być tak opóźniona, że termin upłynął. Mapowanie HTTP: limit czasu bramy 504
NOT_FOUND	Nie znaleziono żądanej encji (np. pliku lub katalogu). Uwaga dla deweloperów serwerów: jeśli żądanie zostanie odrzucone dla całej klasy użytkowników, na przykład na etapie stopniowego wdrażania funkcji lub pojawienia się nieudokumentowanej listy dozwolonych, można użyć NOT_FOUND. Jeśli żądanie zostanie odrzucone w przypadku niektórych użytkowników z klasy, na przykład kontroli dostępu opartej na użytkownikach, należy użyć PERMISSION_DENIED. Mapowanie HTTP: błąd 404 – nie znaleziono
ALREADY_EXISTS	Encja, którą klient próbował utworzyć (np. plik lub katalog), już istnieje. Mapowanie HTTP: konflikt 409
PERMISSION_DENIED	Element wywołujący nie ma uprawnień do wykonania określonej operacji. Nie można używać parametru PERMISSION_DENIED w przypadku odrzuceń spowodowanych wyczerpaniem się niektórych zasobów (w przypadku tych błędów użyj elementu RESOURCE_EXHAUSTED). Nie można używać parametru PERMISSION_DENIED, jeśli nie można zidentyfikować rozmówcy (w przypadku tych błędów użyj elementu UNAUTHENTICATED). Ten kod błędu nie sugeruje, że żądanie jest prawidłowe, żądana jednostka istnieje lub spełnia inne warunki wstępne. Mapowanie HTTP: 403 Forbidden
UNAUTHENTICATED	Żądanie nie ma prawidłowych danych uwierzytelniających dla tej operacji. Mapowanie HTTP: 401 Brak autoryzacji
RESOURCE_EXHAUSTED	Część zasobów została wyczerpana – na przykład limit na użytkownika lub w całym systemie plików nie ma już miejsca. Mapowanie HTTP: 429 zbyt wiele żądań
FAILED_PRECONDITION	Operacja została odrzucona, ponieważ system nie znajduje się w stanie wymaganym do jej wykonania. Na przykład katalog do usunięcia nie jest pusty, operacja rmdir jest stosowana do katalogu niebędącego katalogiem itd. Podmioty implementujące usługi mogą skorzystać z poniższych wskazówek, aby zdecydować, czy jest to FAILED_PRECONDITION, ABORTED czy UNAVAILABLE: (a) Użyj metody UNAVAILABLE, jeśli klient może ponowić próbę wywołania tylko jednego z błędów. (b) Użyj ABORTED, jeśli klient powinien spróbować ponownie na wyższym poziomie. Jeśli na przykład określony przez klienta proces testowania i zestawu nie powiedzie się, oznacza to, że klient powinien ponownie uruchomić sekwencję odczytu, modyfikacji i zapisu. (c) Użyj polecenia FAILED_PRECONDITION, jeśli klient nie powinien ponawiać próby, dopóki stan systemu nie zostanie bezpośrednio poprawiony. Jeśli na przykład parametr „rmdir” nie powiedzie się, ponieważ katalog nie jest pusty, należy zwrócić wartość FAILED_PRECONDITION, ponieważ klient nie powinien ponawiać próby, chyba że pliki zostaną usunięte z katalogu. Mapowanie HTTP: 400 Nieprawidłowe żądanie
ABORTED	Operacja została przerwana, zwykle z powodu problemu równoczesności, takiego jak błąd kontroli sekwencera lub przerwanie transakcji. Powyżej znajdziesz wskazówki, jak wybrać opcję: FAILED_PRECONDITION, ABORTED lub UNAVAILABLE. Mapowanie HTTP: konflikt 409
OUT_OF_RANGE	Podjęto próbę wykonania operacji poza prawidłowym zakresem. Dotyczy to na przykład wyszukiwania lub odczytu ostatniego końca pliku. W przeciwieństwie do zasady INVALID_ARGUMENT ten błąd wskazuje problem, który można rozwiązać w przypadku zmiany stanu systemu. Na przykład 32-bitowy system plików wygeneruje plik INVALID_ARGUMENT, gdy pojawi się żądanie odczytania z przesunięciem spoza zakresu [0,2^32-1], ale wygeneruje OUT_OF_RANGE w przypadku prośby o odczytanie danych z przesunięcia poza aktualny rozmiar pliku. Między FAILED_PRECONDITION i OUT_OF_RANGE występuje w niewielkim stopniu pokrywanie się. W razie potrzeby zalecamy użycie właściwości OUT_OF_RANGE (bardziej szczegółowego błędu), aby osoby wywołujące iterujące w pokoju mogły łatwo znaleźć błąd OUT_OF_RANGE i wykryć zakończenie. Mapowanie HTTP: 400 Nieprawidłowe żądanie
UNIMPLEMENTED	Operacja nie jest wdrożona lub nie jest obsługiwana/włączona w tej usłudze. Mapowanie HTTP: błąd 501 nie zaimplementowano
INTERNAL	Błędy wewnętrzne. Oznacza to, że niektóre niezmienniki oczekiwane przez system bazowy zostały uszkodzone. Ten kod błędu jest zarezerwowany dla poważnych błędów. Mapowanie HTTP: wewnętrzny błąd serwera 500
UNAVAILABLE	Usługa jest obecnie niedostępna. Jest to najprawdopodobniej stan przejściowy, który można skorygować, ponownie próbując z powrotem. Pamiętaj, że nie zawsze można bezpiecznie ponawiać próby wykonania innych operacji, które nie sąidempotentne. Powyżej znajdziesz wskazówki, jak wybrać opcję: FAILED_PRECONDITION, ABORTED lub UNAVAILABLE. Mapowanie HTTP: usługa 503 niedostępna
DATA_LOSS	Nieodwracalna utrata danych lub ich uszkodzenie. Mapowanie HTTP: wewnętrzny błąd serwera 500

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. Każdy komunikat Status zawiera 3 rodzaje danych: kod błędu, komunikat o błędzie i szczegóły błędu.

Więcej informacji o tym modelu błędu i o tym, jak z nim korzystać, znajdziesz w dokumencie API Design Guide (w języku angielskim).

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.