> Date: Sunday, April 19, 2020 09:48:29 -0700
> From: Jeffry Killen <jekillen@xxxxxxxxxxx>
>
>> On Apr 19, 2020, at 8:34 AM, Richard wrote:
>>
>>> Date: Saturday, April 18, 2020 22:20:25 -0700
>>> From: Jeffry Killen <jekillen@xxxxxxxxxxx>
>>>
>>> I did manage to solve this issue.
>>>
>>> It was one of the hardest issues I have had to
>>> deal with and I am not sure what exactly solved
>>> it.
>>>
>>> I did change the submission method to POST
>>> and had to chase through a lot of javascript to
>>> make sure all those ducks were in a row.
>>>
>>> I finally got it to work as expected.
>>>
>>> But not having any indication of why something
>>> is not working is the hardest, considering everything
>>> just before the apparent problem is working correctly.
>>>
>>
>> I have always found that a critical part of programming and
>> debugging is to place "debug" statements strategically throughout
>> my code. That way I can know exactly what various values are at
>> different points and can quickly spot when something isn't as
>> expected.
>>
>> My style is:
>>
>> if ($debug > N) {
>> echo <tag & variable>
>> ...
>> }
>>
>> where I use different values for N to be able to easily turn
>> debugging on and off by section or verboseness - based on the value
>> of $debug that I set.
>>
>> This takes a lot of the guesswork out of debugging things.
>
> Thank you for your thoughts;
>
> I do have a sampling module that I can place at strategic
> locations in code. It writes selected variable values to a
> text file. It is useful in debugging async request processing
> because using echo or print is mostly useless in that situation.
> JK
Yes, obviously what you use to get debug output will vary based on
context - programming language/data flow, etc. - but the point is,
putting in your own debugging points is often critical to successful
programming. You should always be able to know exactly what any value
is at any point in your code.
[i am on the mailing list, please do not include me on the recipient
list.]
