message LatLon {
double lat = 1; // Geodetic latitude, decimal degrees
double lon = 2; // Geodetic longitude, decimal degrees
}
"Hmm, lat = 0, I guess they didn't fill out the message. I'll thrown an exception and handle it as an api error"
[Later, somewhere near the equator]
"?!?!??!"
------------------
"Ok, we learned our lesson from what happened to our customers in Sao Tome and Principe: 0.0 is a perfectly valid latitude to have. No more testing for 0, we'll just trust the value we parse.
[Later, in Norway, when a bug causes a client to skip filling out the LatLon message]
"Why is it flying to Africa?!?!"
------------------
Ok, after the backlash from our equatorial customers and the disaster in Norway, we've learned our lesson. We will now use a new message that lets us handle 0's, but checks that they really meant it:
message LatLonEnforced {
optional double lat = 1;
optional double lon = 2;
}
[At some third party dev's desk]
"Oh, latitude is optional - I'll just supply longitude"
[...]
"It's throwing exceptions? But your schema says it's optional!"
------------------
Ok, it took some blood sweat and tears but we finally got this message definition licked:
message LatLonEnforced {
optional double lat = 1; // REQUIRED. Geodetic latitude, decimal degrees
optional double lon = 2; // REQUIRED. Geodetic longitude, decimal degrees
}
[Later, in an MR from a new hire]
"Correct LatLon doc strings to reflect optional semantics"