The last couple of hours have been quite productive, probably because everyone else is sleeping for a change hehe.
I’ve been working on a simple class that provides the database usage schematics that I desire, namely… If I shoot myself in the foot, when in doubt — explode. And simple iterator support for rows. There are numerous interfaces I’m sure, but I’ve yet to see one that provided *what* I wanted, and it seems faster to write my own rather then keep researching.
The basic frame of thought I have, is if debugging a fuck-up is to costly in time, make sure it is easier to debug. In fact, in implementing the class… I accidentally shot myself in the foot, and the class exploded on me. I tried to implement something without thinking about the state of the supporting code clearly. I had forgotten to support 1 of 2 possible successful outcomes of a lower level method, which assumed any non successful outcome from this method was a critical problem (and it is 99% of times I’ve seen it fail). Since the method is intended for a situation where paranoia is preferred over ignoring problems, and needs to *only* allow correct actions to pass by it’s safe guards. The end result of my lack of thinking being, that I improved the iterator that started the chain reaction to report a problem that never occured to me as possible, and fixed the lower level support method in question to behave correctly, then tested it to ensure it works properly (along with methods depending upon it). If I hadn’t had that failed test initially, I probably wouldn’t have thought about fixing that until the next phase of testing (pre deployment), and would not have made that adjustment to the iterator, until I really got smacked upside the head using it lol.
Not exactly why I designed it the way I have, but it’s starting to pay for itself I guess :