What I really hipChatted you about:
I wanted to know if you had resolved the weirdness about error handling and bubbling from SdssShapeImpl back up through the measurement framework. It is similar to the error issues in SdssCentroid, though slightly more complex.
The SdssShapeImpl code uses an enumeration to set a flags variable as I recall, and then assumes that the enumeration is the same as a second enumeration in SdssShape. I called out this ugliness at one time, but postponed fixing it during the port.
Now doMeasureCentroidImpl is just a pair of anonymous routines, not a class. And one strategy is to just fold this code into the SdssCentroid Algorithm itself, which would make it possible to get to the flagHandler from this routine. Not sure if this is allowed, or if the code should stay separted. But that would be the cleanest approach.
Another choice would be to make a CentroidImpl class and give it a flags variable like SdssShapeImpl has. I don't like this much, but would like to be consistent with whatever you are doing to SdssShape.
Another possibility is to use the old style retval system to return from a list of enumerated errors. I actually like this pretty well, assuming that I can't just absorb this method into the class.
One other question. Do you envision that when a MeasurementError is thrown, the error message could be customized by the thrower, so that the bad values which caused the throw could be published in the log? You may have this already somewhere, though I don't remember seeing it.