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 \ V1
Methods
__construct
Constructor.
Parameters
Name
Description
data
array
Optional. Data for populating the Message object.
↳ code
int
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".
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.
↳ error_message
string
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.
↳ 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:
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:
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.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Google Maps Route Optimization V1 Client - Class OptimizeToursValidationError (0.4.1)\n\nVersion latestkeyboard_arrow_down\n\n- [0.4.1 (latest)](/php/docs/reference/maps-routeoptimization/latest/V1.OptimizeToursValidationError)\n- [0.4.0](/php/docs/reference/maps-routeoptimization/0.4.0/V1.OptimizeToursValidationError)\n- [0.3.3](/php/docs/reference/maps-routeoptimization/0.3.3/V1.OptimizeToursValidationError)\n- [0.2.0](/php/docs/reference/maps-routeoptimization/0.2.0/V1.OptimizeToursValidationError)\n- [0.1.0](/php/docs/reference/maps-routeoptimization/0.1.0/V1.OptimizeToursValidationError) \nReference documentation and code samples for the Google Maps Route Optimization V1 Client class OptimizeToursValidationError.\n\nDescribes an error or warning encountered when validating an\n`OptimizeToursRequest`.\n\nGenerated from protobuf message `google.maps.routeoptimization.v1.OptimizeToursValidationError`\n\nNamespace\n---------\n\nGoogle \\\\ Maps \\\\ RouteOptimization \\\\ V1\n\nMethods\n-------\n\n### __construct\n\nConstructor.\n\n### getCode\n\nA validation error is defined by the pair (`code`, `display_name`) which\nare always present.\n\nThe fields following this section provide more context about the error.\n*MULTIPLE ERRORS* :\nWhen there are multiple errors, the validation process tries to output\nseveral of them. Much like a compiler, this is an imperfect process. Some\nvalidation errors will be \"fatal\", meaning that they stop the entire\nvalidation process. This is the case for `display_name=\"UNSPECIFIED\"`\nerrors, among others. Some errors may cause the validation process to skip\nother errors.\n*STABILITY* :\n`code` and `display_name` should be very stable. But new codes and\ndisplay names may appear over time, which may cause a given (invalid)\nrequest to yield a different (`code`, `display_name`) pair because the new\nerror hid the old one. For example, see \"MULTIPLE ERRORS\".\n\n### setCode\n\nA validation error is defined by the pair (`code`, `display_name`) which\nare always present.\n\nThe fields following this section provide more context about the error.\n*MULTIPLE ERRORS* :\nWhen there are multiple errors, the validation process tries to output\nseveral of them. Much like a compiler, this is an imperfect process. Some\nvalidation errors will be \"fatal\", meaning that they stop the entire\nvalidation process. This is the case for `display_name=\"UNSPECIFIED\"`\nerrors, among others. Some errors may cause the validation process to skip\nother errors.\n*STABILITY* :\n`code` and `display_name` should be very stable. But new codes and\ndisplay names may appear over time, which may cause a given (invalid)\nrequest to yield a different (`code`, `display_name`) pair because the new\nerror hid the old one. For example, see \"MULTIPLE ERRORS\".\n\n### getDisplayName\n\nThe error display name.\n\n### setDisplayName\n\nThe error display name.\n\n### getFields\n\nAn error context may involve 0, 1 (most of the time) or more fields. For\nexample, referring to vehicle #4 and shipment #2's first pickup can be\ndone as follows: \n\n fields { name: \"vehicles\" index: 4}\n fields { name: \"shipments\" index: 2 sub_field {name: \"pickups\" index: 0} }\n\nNote, however, that the cardinality of `fields` should not change for a\ngiven error code.\n\n### setFields\n\nAn error context may involve 0, 1 (most of the time) or more fields. For\nexample, referring to vehicle #4 and shipment #2's first pickup can be\ndone as follows: \n\n fields { name: \"vehicles\" index: 4}\n fields { name: \"shipments\" index: 2 sub_field {name: \"pickups\" index: 0} }\n\nNote, however, that the cardinality of `fields` should not change for a\ngiven error code.\n\n### getErrorMessage\n\nHuman-readable string describing the error. There is a 1:1 mapping\nbetween `code` and `error_message` (when code != \"UNSPECIFIED\").\n\n*STABILITY* : Not stable: the error message associated to a given `code` may\nchange (hopefully to clarify it) over time. Please rely on the\n`display_name` and `code` instead.\n\n### setErrorMessage\n\nHuman-readable string describing the error. There is a 1:1 mapping\nbetween `code` and `error_message` (when code != \"UNSPECIFIED\").\n\n*STABILITY* : Not stable: the error message associated to a given `code` may\nchange (hopefully to clarify it) over time. Please rely on the\n`display_name` and `code` instead.\n\n### getOffendingValues\n\nMay contain the value(s) of the field(s). This is not always available. You\nshould absolutely not rely on it and use it only for manual model\ndebugging.\n\n### setOffendingValues\n\nMay contain the value(s) of the field(s). This is not always available. You\nshould absolutely not rely on it and use it only for manual model\ndebugging."]]
