>>>Beside other reasons mentioned elsewhere in this thread, I would consider your example as bad programming for a couple of reasons:
>>>
>>>1. Validating the parameter: The parameter, in this case, is used for querying data, therefore it must be validated as having the same data type. Calling functions may not be aware of the data structures, or even the furhter use of the value passed as the parameter. Obviously, that would be the requirement of the function dealing directly with data, which called function in this case is aware of the data structure.
>>
>>So, what should happen if the calling function sent a wrong type of variable? I mean, isn't the error and exception handler the legitimate way to go?
>
>Yes, that would be a legitimate way to go, however error/exception handler is not listed as an assumption in your original message. Furthermore, as a programmer I would make sure that an error like this is handled properly/safely, which is really the point here.

The native e/e handler may not be the most useful one, but it is an e/e handler afterall.

>>
>>>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.

>>>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.