Google Maps Route Optimization V1 Client - Class OptimizeToursValidationError (0.5.1)

Reference documentation and code samples for the Google Maps Route Optimization V1 Client class OptimizeToursValidationError.

Describes an error or warning encountered when validating an OptimizeToursRequest.

Generated from protobuf message google.maps.routeoptimization.v1.OptimizeToursValidationError

Constructor.

A validation error is defined by the pair (code, display_name) which are always present.

The fields following this section provide more context about the error. MULTIPLE ERRORS: When there are multiple errors, the validation process tries to output several of them. Much like a compiler, this is an imperfect process. Some validation errors will be "fatal", meaning that they stop the entire validation process. This is the case for display_name="UNSPECIFIED" errors, among others. Some errors may cause the validation process to skip other errors. STABILITY: code and display_name should be very stable. But new codes and display names may appear over time, which may cause a given (invalid) request to yield a different (code, display_name) pair because the new error hid the old one. For example, see "MULTIPLE ERRORS".

A validation error is defined by the pair (code, display_name) which are always present.

The fields following this section provide more context about the error. MULTIPLE ERRORS: When there are multiple errors, the validation process tries to output several of them. Much like a compiler, this is an imperfect process. Some validation errors will be "fatal", meaning that they stop the entire validation process. This is the case for display_name="UNSPECIFIED" errors, among others. Some errors may cause the validation process to skip other errors. STABILITY: code and display_name should be very stable. But new codes and display names may appear over time, which may cause a given (invalid) request to yield a different (code, display_name) pair because the new error hid the old one. For example, see "MULTIPLE ERRORS".

The error display name.

The error display name.

An error context may involve 0, 1 (most of the time) or more fields. For example, referring to vehicle #4 and shipment #2's first pickup can be done as follows:

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 sub_field {name: "pickups" index: 0} }

Note, however, that the cardinality of fields should not change for a given error code.

An error context may involve 0, 1 (most of the time) or more fields. For example, referring to vehicle #4 and shipment #2's first pickup can be done as follows:

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 sub_field {name: "pickups" index: 0} }

Note, however, that the cardinality of fields should not change for a given error code.

Human-readable string describing the error. There is a 1:1 mapping between code and error_message (when code != "UNSPECIFIED").

STABILITY: Not stable: the error message associated to a given code may change (hopefully to clarify it) over time. Please rely on the display_name and code instead.

Human-readable string describing the error. There is a 1:1 mapping between code and error_message (when code != "UNSPECIFIED").

STABILITY: Not stable: the error message associated to a given code may change (hopefully to clarify it) over time. Please rely on the display_name and code instead.

May contain the value(s) of the field(s). This is not always available. You should absolutely not rely on it and use it only for manual model debugging.

May contain the value(s) of the field(s). This is not always available. You should absolutely not rely on it and use it only for manual model debugging.