|
14 | 14 |
|
15 | 15 | syntax = "proto3"; |
16 | 16 |
|
17 | | -package google.rpc; |
| 17 | +// This package is for internal use by Connect, and provides no backward |
| 18 | +// compatibility guarantees whatsoever. |
| 19 | +package grpc.status.v1; |
18 | 20 |
|
19 | 21 | import "google/protobuf/any.proto"; |
20 | 22 |
|
21 | | -option go_package = "google.golang.org/genproto/googleapis/rpc/status;status"; |
22 | | -option java_multiple_files = true; |
23 | | -option java_outer_classname = "StatusProto"; |
24 | | -option java_package = "com.google.rpc"; |
25 | | -option objc_class_prefix = "RPC"; |
26 | | - |
27 | | -// The `Status` type defines a logical error model that is suitable for different |
28 | | -// programming environments, including REST APIs and RPC APIs. It is used by |
29 | | -// [gRPC](https://github.com/grpc). The error model is designed to be: |
30 | | -// |
31 | | -// - Simple to use and understand for most users |
32 | | -// - Flexible enough to meet unexpected needs |
33 | | -// |
34 | | -// # Overview |
35 | | -// |
36 | | -// The `Status` message contains three pieces of data: error code, error message, |
37 | | -// and error details. The error code should be an enum value of |
38 | | -// [google.rpc.Code][google.rpc.Code], but it may accept additional error codes if needed. The |
39 | | -// error message should be a developer-facing English message that helps |
40 | | -// developers *understand* and *resolve* the error. If a localized user-facing |
41 | | -// error message is needed, put the localized message in the error details or |
42 | | -// localize it in the client. The optional error details may contain arbitrary |
43 | | -// information about the error. There is a predefined set of error detail types |
44 | | -// in the package `google.rpc` which can be used for common error conditions. |
45 | | -// |
46 | | -// # Language mapping |
47 | | -// |
48 | | -// The `Status` message is the logical representation of the error model, but it |
49 | | -// is not necessarily the actual wire format. When the `Status` message is |
50 | | -// exposed in different client libraries and different wire protocols, it can be |
51 | | -// mapped differently. For example, it will likely be mapped to some exceptions |
52 | | -// in Java, but more likely mapped to some error codes in C. |
53 | | -// |
54 | | -// # Other uses |
55 | | -// |
56 | | -// The error model and the `Status` message can be used in a variety of |
57 | | -// environments, either with or without APIs, to provide a |
58 | | -// consistent developer experience across different environments. |
| 23 | +// See https://cloud.google.com/apis/design/errors. |
59 | 24 | // |
60 | | -// Example uses of this error model include: |
61 | | -// |
62 | | -// - Partial errors. If a service needs to return partial errors to the client, |
63 | | -// it may embed the `Status` in the normal response to indicate the partial |
64 | | -// errors. |
65 | | -// |
66 | | -// - Workflow errors. A typical workflow has multiple steps. Each step may |
67 | | -// have a `Status` message for error reporting purpose. |
68 | | -// |
69 | | -// - Batch operations. If a client uses batch request and batch response, the |
70 | | -// `Status` message should be used directly inside batch response, one for |
71 | | -// each error sub-response. |
72 | | -// |
73 | | -// - Asynchronous operations. If an API call embeds asynchronous operation |
74 | | -// results in its response, the status of those operations should be |
75 | | -// represented directly using the `Status` message. |
76 | | -// |
77 | | -// - Logging. If some API errors are stored in logs, the message `Status` could |
78 | | -// be used directly after any stripping needed for security/privacy reasons. |
| 25 | +// This struct must remain binary-compatible with |
| 26 | +// https://github.com/googleapis/googleapis/blob/master/google/rpc/status.proto. |
79 | 27 | message Status { |
80 | | - // The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code]. |
81 | | - int32 code = 1; |
82 | | - |
83 | | - // A developer-facing error message, which should be in English. Any |
84 | | - // user-facing error message should be localized and sent in the |
85 | | - // [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client. |
86 | | - string message = 2; |
87 | | - |
88 | | - // A list of messages that carry the error details. There will be a |
89 | | - // common set of message types for APIs to use. |
| 28 | + int32 code = 1; // a google.rpc.Code |
| 29 | + string message = 2; // developer-facing, English (localize in details or client-side) |
90 | 30 | repeated google.protobuf.Any details = 3; |
91 | 31 | } |
0 commit comments