# Debugging Clarion Programs **URL:** \ **Category:** docs\ **Tags:** debugging\ **Created:** [February 22, 2015, 5:29pm UTC](https://clarionhub.com/t/debugging-clarion-programs/312 "2015-02-22T17:29:47Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![brahn](https://clarionhub.com/user_avatar/clarionhub.com/brahn/32/756_2.png) [@brahn](https://clarionhub.com/u/brahn)\ **Post date:** [February 22, 2015, 5:29pm UTC](https://clarionhub.com/t/debugging-clarion-programs/312/1 "2015-02-22T17:29:47Z")
Originally Presented by [Russell B. Eggen](https://reggen.wordpress.com/), [RADFusion](http://www.radfusion.com/), 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 `SUSPEND`ed 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](https://clarionhub-uploads.s3.dualstack.eu-north-1.amazonaws.com/original/2X/1/114b368c449d6ae7512eaaa1b277dad6da9b5369.pdf) (868.0 KB) Also, don’t forget ClarionLive [Webinar 073 - Russ Eggen and All About Debugging](http://clarionlive.com/index.php?option=com_docman&task=doc_details&gid=113&Itemid=57)