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
Namespace
Google \ Maps \ RouteOptimization \ V1Methods
__construct
Constructor.
| Parameters | |
|---|---|
| Name | Description |
data |
array
Optional. Data for populating the Message object. |
↳ code |
int
A validation error is defined by the pair ( |
↳ display_name |
string
The error display name. |
↳ fields |
array<OptimizeToursValidationError\FieldReference>
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: |
↳ error_message |
string
Human-readable string describing the error. There is a 1:1 mapping between |
↳ offending_values |
string
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. |
getCode
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".
| Returns | |
|---|---|
| Type | Description |
int |
|
setCode
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".
| Parameter | |
|---|---|
| Name | Description |
var |
int
|
| Returns | |
|---|---|
| Type | Description |
$this |
|
getDisplayName
The error display name.
| Returns | |
|---|---|
| Type | Description |
string |
|
setDisplayName
The error display name.
| Parameter | |
|---|---|
| Name | Description |
var |
string
|
| Returns | |
|---|---|
| Type | Description |
$this |
|
getFields
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.
| Returns | |
|---|---|
| Type | Description |
Google\Protobuf\Internal\RepeatedField |
|
setFields
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.
| Parameter | |
|---|---|
| Name | Description |
var |
array<OptimizeToursValidationError\FieldReference>
|
| Returns | |
|---|---|
| Type | Description |
$this |
|
getErrorMessage
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.
| Returns | |
|---|---|
| Type | Description |
string |
|
setErrorMessage
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.
| Parameter | |
|---|---|
| Name | Description |
var |
string
|
| Returns | |
|---|---|
| Type | Description |
$this |
|
getOffendingValues
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.
| Returns | |
|---|---|
| Type | Description |
string |
|
setOffendingValues
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.
| Parameter | |
|---|---|
| Name | Description |
var |
string
|
| Returns | |
|---|---|
| Type | Description |
$this |
|