>>>>2. Assuming there's one record found: Expecting data to have a certain structure is a design requirement, whereas assuming data to have (a number of) records is bad programming IMO. However, that wouldn't be such a big problem if the subsequent code would not crash with a "variable 'laEmpName' not found", in case no records are found. So, the other bad thing is assuming that a variable is instantiated by a statement producing ambigous results (like SELECT INTO ARRAY). That's rather poor programming, hardly a design flaw.
>>>
>>>Why can't assuming records be a design requirement?
>>
>>Because, for records other than metadata, it rarely is.
>>
>>>Suppose they are promised in the specs, wouldn't that make it unnecessary to check _tally? I can imagine that there is supposed to be a 1-n relationship where n>0 between 2 tables. E.g. routine 1 has found an id in the relations table. Routine 2 will search for the address of that relation in the address table. During input of the person the app has taken care of it that there is always at least one entry in the address table for that id. Why check whether _tally>0? What's bad about the design if that's not done?
>>>
>>
>>Well, if everything is promised in the spec, then sure :) However, imagine that you have an entities table and an events table and your routine is querying the events table for an entity that has no relevant events. I wouldn't think an error would suffice in this case, would you?
>
>If that situation is possible, then there is a 1-n relationship where n>=0. And the specs should also cover the situation where n=0 indeed. It would be an explicit impetus for the programmer to use _tally.

The situation is not only possible, but probable.

>
>>>>3. Assuming that the spec/documentation is always perfect without questioning it, is bad programming :)
>>>
>>>I'd say that the defensive programming style you're promoting is based on cynicism and skepticism towards the designers. A flaw in the functional specs is, in the end, not the reponsibility of the programmer.
>>
>>I'd say you go too far with your assumptions. I am not judging the designer, though I would rather question the design, as in trying to find answers to my questions.
>>Maybe this discussion should be about the design, since everything is supposed to be covered there. Not about the programming, or the designer.
>
>Let's face it, many of us have developed an attitude of skepticism and even cynicism towards functional specs. But is the 'defensive programming style' the right reaction? Some of us know that the specs almost certainly contain flaws, but nevertheless continue to code asif those specs are perfect. They accept that the code will crash at places and are not afraid to point the finger towards the functional designers room. Are they wrong, right or merely arrogant?
>
>The point I'm trying to make here is that a defensive programming style may well be an overreaction and a sign of fear. Fear that others will blame you, the programmer, for every flaw in the product. The positive effect of this fear may be that the product will probably become more robust. The downside may be that development time will probably increase significantly, due to checks and double-checks that will always (yes, litterally always) gonna produce the same outcome.

What I'm saying here (like mostly everybody else) is that programming assummes a certain level of common sense and consideration. Nobody is advocating for extremely defensive programming, but the assumptions that the spec would cover everything, and the programming style suggested in your example, are rather frivolous.
Does your company really have a room for functional designers? :)