// Copyright 2016 Google Inc.

//

// Licensed under the Apache License, Version 2.0 (the "License");

// you may not use this file except in compliance with the License.

// You may obtain a copy of the License at

//

// http://www.apache.org/licenses/LICENSE-2.0

//

// Unless required by applicable law or agreed to in writing, software

// distributed under the License is distributed on an "AS IS" BASIS,

// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

// See the License for the specific language governing permissions and

// limitations under the License.

syntax = "proto3";

package google.rpc;

import "google/protobuf/any.proto";

option go_package = "google.golang.org/genproto/googleapis/rpc/status;status";

option java_multiple_files = true;

option java_outer_classname = "StatusProto";

option java_package = "com.google.rpc";

option objc_class_prefix = "RPC";

// The `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:

//

// - Simple to use and understand for most users

// - Flexible enough to meet unexpected needs

//

// # Overview

//

// The `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][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` which can be used for common error conditions.

//

// # Language mapping

//

// The `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.

//

// # Other uses

//

// The 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.

//

// Example uses of this error model include:

//

// - 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.

//

// - Workflow errors. A typical workflow has multiple steps. Each step may

// have a `Status` message for error reporting purpose.

//

// - 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.

//

// - 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.

//

// - Logging. If some API errors are stored in logs, the message `Status` could

// be used directly after any stripping needed for security/privacy reasons.

message Status {

}