Originally Presented by Russell B. Eggen, RADFusion, Inc. at the Aussie DevCon 2006. Distributed here with permission from @reggen !
CHAPTER 1 - DEBUGGING
Why Debug?
It does not matter how bright or clever you are or how well one can study and apply a topic. You
will encounter some undesirable behavior when running or testing your code. Bugs exist in all sorts
of forms, not just from your code either.
Your code may indeed be at fault. You may have incorrectly coded something or the code works
100% yet still the application does not work. That situation is fairly common, yet the cause is
hiding in plain sight – missing code!
It may be the cause of the problem is the vendor’s fault. Documented behavior does not match
what you are observing, or it just plain does not work.
The problem may stem from a 3rd party product inserted into your code. That can be tricky to
isolate. Common in this group is the 3rd party vendor says its Softvelocity’s bug and vice versa.
There are reasons to come to either conclusion.
Bugs do arise from data errors too. How many times have you tested code, proved it works, yet
when installed at a client’s site, it does not? Ever try to hook up a relation only to find it does not
see related records or even worse, the wrong ones? Usually, but not always clients introduce these
bugs, most commonly from conversion processes.
Don’t Code Bugs!
In a perfect world, you would just not code bugs. Some Clarion developers claim they don’t need
debuggers as they don’t code bugs. These few state they use templates to generate perfect code
every time. Granted, that is a great tool to prevent common bugs. But those that state they don’t
code bugs are not believable. When they wrote those templates, did it work the first time they used
them? The more complex the template, the more ridiculous their claim is.
The best advice on coding I ever received stated simply; “If you are not coding bugs, you are not
coding hard enough.”
That does not mean one ships bug ridden code! It means that no matter how careful you are, you
should be seeing a bug here and there. Coding, compiling, testing and fixing are all part of the
development cycle. Just writing code is a small part of the effort.
Just like a writer who never makes grammar and spelling errors, no developer is immune from
syntax errors and typos (which the compiler catches), or a short burst of temporary bad logic.
Computers Never Lie, But They are Often Wrong
One common, yet frustrating debug process is the “there is nothing wrong with this code, but my
application does not work”. The temptation here is to jump to conclusions. By that I mean not a
proper investigation as to why.
I was once working on a bit of code that had a cosmetic issue that was driving me nuts. A second
pair of eyes is often useful. This very talented programmer jumped to a conclusion by stating it must be C6 and thread timing. Turned out that a SUSPENDed thread never gets a chance to cycle
through it’s ACCEPT loop. The solution required redesign of my code.
Of course the old favorite that always comes up when a new release arrives. “My code no longer
works, went back to the previous version, it works again. Bug in new release!” Hate to break this
to you, but that is not a proper investigation! It is an incomplete investigation as observation of a
bug is the first step. If you can still ask “Why?”, you need to dig more. How many times has
something in Clarion been fixed, when no one knew about the bug existed only to cause a slight
change in behavior? You usually see this around the drivers or statements that may affect them.
You need to find out if something changed in the statement or driver. If so, you may need to adjust
your code.
With Clarion 6.x, and the threading changes from earlier releases, expect behavior changes. How
you deal with version issues is a good reason to become good at debugging, especially when
upgrading your existing “stable” applications. Clarion 7 is just around the corner.
One infamous example of this was an undocumented change between Clarion 5 and 5.5. About 3
SQL tables stopped giving us a unique ID. This was passed to a function that required a unique ID,
which promptly GPF’d. Turns out one of the driver strings were case sensitive in 5.5. This raised a
new connection and the expect ID did not match, thus the function failed with a GPF. Of course,
the function was fixed to not GPF as well.
What is a good Debugger?
To answer that, it depends on what you need at the time you notice non-optimum behavior in your
application. For the rest of this session, I intend to cover the following topics:
- The Clarion Debugger
- Driver debugging
- API Debugging
- Third party offerings
Each of the above you should know. You may not need them all for most things, but you will need
them eventually.
Read on for the rest!
Debugging.pdf (868.0 KB)
Also, don’t forget ClarionLive Webinar 073 - Russ Eggen and All About Debugging