Autogenerated update (2019-06-06)
Update: - androidenterprise_v1 - androidpublisher_v3 - bigquery_v2 - cloudprivatecatalogproducer_v1beta1 - cloudresourcemanager_v1 - cloudresourcemanager_v2 - cloudresourcemanager_v2beta1 - container_v1 - containeranalysis_v1alpha1 - containeranalysis_v1beta1 - content_v2 - content_v2_1 - dlp_v2 - fcm_v1 - file_v1 - file_v1beta1 - gmail_v1 - healthcare_v1alpha2 - healthcare_v1beta1
This commit is contained in:
Google APIs committed
1 parent
827d93636f
commit
5b4eab2abf
54 files changed
+1180
-820
No files matched your search
@@ -848,43 +848,10 @@ module Google
|
||||
|
||||
# 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, 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.
|
||||
# # 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.
|
||||
# - 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.
|
||||
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||
# three pieces of data: error code, error message, and error details.
|
||||
# You can find out more about this error model and how to work with it in the
|
||||
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||
# Corresponds to the JSON property `analysisStatusError`
|
||||
# @return [Google::Apis::ContaineranalysisV1alpha1::Status]
|
||||
attr_accessor :analysis_status_error
|
||||
@@ -1868,43 +1835,10 @@ module Google
|
||||
|
||||
# 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, 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.
|
||||
# # 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.
|
||||
# - 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.
|
||||
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||
# three pieces of data: error code, error message, and error details.
|
||||
# You can find out more about this error model and how to work with it in the
|
||||
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||
# Corresponds to the JSON property `error`
|
||||
# @return [Google::Apis::ContaineranalysisV1alpha1::Status]
|
||||
attr_accessor :error
|
||||
@@ -2450,43 +2384,10 @@ module Google
|
||||
|
||||
# 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, 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.
|
||||
# # 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.
|
||||
# - 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.
|
||||
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||
# three pieces of data: error code, error message, and error details.
|
||||
# You can find out more about this error model and how to work with it in the
|
||||
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||
class Status
|
||||
include Google::Apis::Core::Hashable
|
||||
|
||||
|
||||
Reference in new issue
Block a user