When Undefined Behaviors Collide
I’m in the fun phase of development right now where I have a mostly functional new implementation of a function, several thousand items of test data that need hand checked because it’s only about 90% likely to be correct because it’s stale, minimal documentation of the old function and dozens of test failures.
Down from hundreds today, and most of them are classes of failures so one fix knocks out a huge number of data points.
One of the big bugs problems that I fixed, it was actually causing the function to throw an error rather than function, was that the old program I’m working on silently just sets any incorrectly parsed number from the database to zero. Java on the other hand, throws an exception.
Which is recoverable, and nice to know about, but problematic when one assumes that the fields storing the data will only contain valid data.
Of course, without definite documentation I can’t be sure the string isn’t valid data, so much as it’s not valid data in the context of the function that I’m working on.
The other interesting thing is that I find it easier to look at a very long list of failure information to try to identify shared data in similar failures.
All in all, it’s a big win for testing, I’m fixing a lot of edge and corner cases, but it’s an even bigger case for needing useful specifications on data structures, and a reminder why throwing generic key/value pairs into a SQL table to store options is a bad pattern.