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

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

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