On Thu, Mar 22, 2012 at 3:27 AM, Andy Allan <gravityst...@gmail.com> wrote: > Finally, in other projects I follow the convention of "don't code > defensively", as described at > http://www.erlang.se/doc/programming_rules.shtml#HDR11 and elsewhere.
Quote: "The function will crash if Option neither normal nor all, and it should do that. The caller is responsible for supplying correct input. " So in their example, the worst that happens is a function fails to do something (and probably raises an exception which is caught at a higher level). In our case, we write data to a shared database that the user has no way of detecting and retrieving (in the case of one-length ways). Defensive programming has its place. > The save code should "trust" that the data is good. If the data isn't > good, whatever made it bad should be fixed. Otherwise it's turtles all > the way down - should the save code check the ids are actually > numerical, just in case, should it do x, y or z, just in case? If any of those things are genuine possibilities, are not checked for by server-side code, and would be harmful, then checking is worth considering. IMHO. > So the > answer is that the input should be checked, somewhere in the > controller code, and then it should be trusted. And our strategy for preventing future such bugs? >My initial thought would be to not create the way until the second >node was drawn. I think that would also remove a lot of the gnarlyness >around POI creation, where we are footling with the >way-that-we-never-actually-wanted as we finish handling the double >click. FYI that change will break my recent fix for undo/redo of new ways. Steve _______________________________________________ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
