Indeks
Kod
Kanoniczne kody błędów interfejsów API gRPC.
Czasami może pojawić się kilka kodów błędów. Usługi powinny zwracać najbardziej szczegółowy kod błędu, który ma zastosowanie. Na przykład w przypadku obu kodów preferuj OUT_OF_RANGE
, a nie FAILED_PRECONDITION
. Podobnie wolą opcję NOT_FOUND
lub ALREADY_EXISTS
zamiast FAILED_PRECONDITION
.
Wartości w polu enum | |
---|---|
OK |
To nie jest błąd. zwracanych w przypadku sukcesu. Mapowanie HTTP: 200 OK |
CANCELLED |
Operacja została anulowana, zwykle przez osobę wywołującą. Mapowanie HTTP: żądanie zamknięcia klienta 499 |
UNKNOWN |
Nieznany błąd. Ten błąd może być zwracany na przykład wtedy, gdy wartość Mapowanie HTTP: wewnętrzny błąd serwera 500 |
INVALID_ARGUMENT |
Klient podał nieprawidłowy argument. Pamiętaj, że różni się to od Mapowanie HTTP: nieprawidłowe żądanie 400 |
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 wtedy, gdy operacja zakończyła się pomyślnie. Na przykład pomyślna odpowiedź serwera mogła być tak opóźniona, że termin upłynął. Mapowanie HTTP: przekroczenie limitu czasu bramy 504 |
NOT_FOUND |
Nie udało się znaleźć żądanej jednostki (np. pliku lub katalogu). Uwaga dla programistów serwerów: jeśli żądanie zostanie odrzucone w przypadku całej klasy użytkowników (np. stopniowe wdrażanie funkcji lub nieudokumentowana lista dozwolonych), może zostać użyta Mapowanie HTTP: Nie znaleziono błędu 404 |
ALREADY_EXISTS |
Encja, którą klient próbował utworzyć (np. plik lub katalog), już istnieje. Mapowanie HTTP: konflikt 409 |
PERMISSION_DENIED |
Wywołujący nie ma uprawnień do wykonania określonej operacji. Parametru Mapowanie HTTP: kod 403 (Zabroniony) |
UNAUTHENTICATED |
Żądanie nie ma prawidłowych danych uwierzytelniających dla tej operacji. Mapowanie HTTP: błąd 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 brakuje 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 została zastosowana do elementu innego niż katalog itd. Implementatory usług mogą wybierać między Mapowanie HTTP: nieprawidłowe żądanie 400 |
ABORTED |
Operacja została przerwana, zwykle z powodu problemu równoczesności, takiego jak błąd kontroli sekwencera lub przerwanie transakcji. Zapoznaj się z powyższymi wskazówkami, aby wybrać tę opcję: Mapowanie HTTP: konflikt 409 |
OUT_OF_RANGE |
Podjęto próbę wykonania operacji poza prawidłowym zakresem. Może to być np. przewinięcie do końca pliku lub odczyt. W przeciwieństwie do zasady Zakres dat Mapowanie HTTP: nieprawidłowe żądanie 400 |
UNIMPLEMENTED |
Ta operacja nie została wdrożona albo nie jest obsługiwana lub włączona w tej usłudze. Mapowanie HTTP: kod 501 (nie zaimplementowano) |
INTERNAL |
Błędy wewnętrzne. Oznacza to, że pewne 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. Najprawdopodobniej jest to stan przejściowy, który można rozwiązać, ponawiając próby. Pamiętaj, że ponawianie operacji nieidempotentnych nie zawsze jest bezpieczne. Zapoznaj się z powyższymi wskazówkami, aby wybrać tę opcję: Mapowanie HTTP: Usługa niedostępna 503 |
DATA_LOSS |
Nieodwracalna utrata lub uszkodzenie danych. Mapowanie HTTP: wewnętrzny błąd serwera 500 |
Stan
Typ Status
określa logiczny model błędów odpowiedni dla różnych środowisk programowania, w tym interfejsów API typu REST i RPC. Jest używany przez gRPC. Każdy komunikat Status
zawiera 3 elementy danych: kod błędu, komunikat o błędzie i szczegóły błędu.
Więcej informacji na temat tego modelu błędów i sposobu jego działania znajdziesz w przewodniku API Design Guide (w języku angielskim).
Pola | |
---|---|
code |
Kod stanu, który powinien być wartością wyliczeniową równą |
message |
komunikat o błędzie widoczny dla dewelopera. Powinien być w języku angielskim; Każdy komunikat o błędzie widoczny dla użytkowników powinien zostać zlokalizowany i wysłany w polu |
details[] |
Lista komunikatów ze szczegółami błędu. Istnieje typowy zestaw typów wiadomości, których mogą używać interfejsy API. |