Re: R: RPG Indicators

[bmorris@xxxxxxxxxx]

>Date: Wed, 19 Apr 2000 23:12:52 +0200
>From: Anton_Gombkötö <Gombkoetoe@ASsoft.com>
>
>>From: Jon Paris
>>I believe Hans commented previously that they were looking at ways of
>>making the BIFS "debuggable" in the future.
>
>Maybe there's an "internal" field like for the null indicator that can be
>debugged?
> ...
> Is there? If not, such fields would do!

Sorry, but I don't think there will ever be debuggable values for
the bifs.  Some of the bifs do have associated internal fields
(currently, but maybe not in the future if we find some case that
can only be determined by generated code) and some require generated
code to determine the value.  Even within the same bif, some files
require generated code for the bif and some can use an internal field.

For the bifs that require generated code, a debugger value would only
be reliable after the statement containing that bif had been executed,
and then only if that particular bif had been evaluated.

For example:

1 c            read(e)   file
2 c            if        %error or %eof(file)
3 c            do something
4 c            endif
5 c            do something else

If %error is on, %eof would not be evaluated, so a debugger value for
%eof would be unreliable.

I would never support changing the rules for short-circuit evaluation
under debug, since that would cause other debug-only changes that might
make a program run differently (e.g. if a procedure call was involved in a
conditional statement and the call was made only during debug because
the truth-value of the statement could be determined without the call).

I know how nice debuggable bifs would be.  While I was unit-testing
this enhancement, I sometimes had to temporarily change my test cases,
adding code to save the value of a bif.  If it had been possible to
add debuggable versions of the bifs, I would have done it.

A final personal opinion: using the debugger is good for finding
problems, but the debugger shouldn't should be used as a quick and easy
method for testing.  Permanent self-checking testcases should be created.
The time taken to create testcases is never wasted - if you write a
testcase that specifically tests a section of code and some maintenance
programmer (maybe you) comes along later and messes it up, the test
case will find it immediately.

I guess that wasn't quite my final opinion.  Here's another one: there's
nothing wrong with writing your code so it's easy to debug.  That usually
makes it easy to read (and test) too.  If you really need to know in the
debugger whether it was %error or %eof that took you into a section of
code, then maybe your code would be better with two separate if's.

Barbara Morris


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---