Re: Debug %found and other BIFs

Joe Pluta wrote:
> 
> That's true, Barbara, but there may well be times especially in debugging
> that I want to set those flags just to quickly test severe error conditions.
> This happens often in boundary testing where I really don't want to have to
> purposely corrupt the database, but I want to make sure my code executes
> properly in case it does get corrupted.
> 
> With indicators, it's quite easy to feign a missing master record.  With
> BIFs it's much more difficult.
> 

Ya, I understand what you mean, and in cases like faking an error, it
doesn't matter that you don't have a real error condition.  But even if
there are some reasonable cases where it would be ok to set a feedback
bif in the debugger, I don't think it argues that the bifs _should_ be
assignable in the debugger.

"Write your code to be testable" is a rule I read somewhere (I wish I
could remember where, and I wish I could follow this rule better myself
... :).  When coding something like error checking, when you know it
would be difficult or even dangerous to actually generate an error, this
rule suggests that you should code a variable to hold the have-an-error
value right from the start.

(But the reason the bifs aren't debuggable is technical, not
ideological.  In most cases, there is a single compiler temporary to
track the feedback bifs, but in some cases there is actual code that is
run to get the value.  We didn't make the bifs debuggable for two
reasons: 1) it would be inconsistent to have some debuggable and some
not;  2) we didn't want to paint ourselves in a corner if we needed to
change a bif from the debuggable-temporary kind to the needs-to-run-code
kind.)