Debugging Your Code: Techniques

Errors are a part of programming. Knowing how to find and fix your mistakes is as important as knowing how to write the code in the first place. The following is a description of the types of errors you will likely encounter while programming in Sesame. For a description of these types of errors, see the Knowledge Base article Debugging Your Code: Types of Errors.

When you Test a program with a Syntax Error, an explanation of the error(s) appears in the Error Window. It may be helpful (and less intimidating) to keep in mind that one error is several lines long, and that errors can cascade. Often, fixing the first one clears all the others. Click on an error (it is recommended that you start with the first/top error) in the Error Window and Sesame will take you to the line of code where it found the problem (for this reason, Syntax Errors are usually easy to find and fix). Read it carefully for spelling and/or syntax errors. Be aware that a problem like a missing quote mark may cause the error marker to land a few lines after where the quote mark is actually missing. You may need to look a few lines prior to the flagged line to find your problem, but you should never need to look at any lines after the flagged line. Logical Errors occur when Sesame is doing exactly what you told it to, and that is the problem. Sesame provides tools to help you locate your logical errors: 1. Run your code
Sometimes the best clue as to why your code isn't doing what you want can be found by looking at what it is doing. 2. Style
Following good programming practices can save you a tremendous amount of time and frustration when it comes to finding errors. Consistent style and good indenting go a long way. See Appendix 2 of the Sesame Programming Guide, or Good Programming Practices - another Knowledge Base article - for valuable programming tips. 3. Simplify
Simplify your code as much as possible. Eliminate problem-causers, then put them back in, one by one, and see which one brings back the problem. There are two ways to do this:

Replace variable values with hard coded values. If your code works with hard coded values, the problem is the variables. Otherwise, the problem is in the code itself.

// If this doesn't work...
Total = Units * Price

// But this does...
Total = 10 * Price

// Then the problem is likely with the value of Units Comment out parts of your code. You can comment out a single line of code with two slashes. (The Q&A REM statement still works, but it is not recommended.) // This is a comment You can comment out entire blocks of code with /* */. /*
This entire block of lines
is commented out. Nothing inside the
comment markers will run.
*/

// If this doesn't work...
While (vLoop < 100)
{
	If(Total > 500)
	{
		Message = "Thank you for your order"
	}
	vLoop += 1
}


// But this does...
While (vLoop < 100)
{
/*
	If(Total > 500)
	{
		Message = "Thank you for your order"
	}
*/
	vLoop += 1
}


// Then the problem is somewhere in the If condition.

4. WriteLn Window
You can use the WriteLn window in Runtime or Preview Mode to print out status messages as your code runs. (For a detailed description of the WriteLn command, see p.434 of the Sesame Programming Guide.) This is useful for determining if a block of code is actually running or showing the values of variables as you operate on them. Note that, because the WriteLn window is a popup, it can cause additional events, especially On Element Entry and On Element Exit events that would not normally occur. This can make an event appear to run multiple times when it would not normally do so. // If "GOT IN HERE" does not appear, then the // condition is never coming true. While(vLoop < 100) { If(Total > 500) { WriteLn("GOT IN HERE") Message = "Thank you for your order" } vLoop += 1 } 5. Illegal Name Warnings
If the name is not being used in programming, these warnings can be ignored. If the name is used in programming, it will cause a syntax error when you use Test Program. Layout element names are legal unless they fall under one of the following categories:

• They are a reserved word. Reserved words are things like built-in command names and their abbreviations. (See the Knowledge Base article Rules For Naming Layout Elements.) For a list of Reserved Words, see the Reserved Words article in this Knowledge Base, or Appendix 3 of the Sesame Programming Guide
• Sesame element names cannot contain operator characters: + - / * = < > [ ] ( ) { } ! ; @ (and similar characters). They can include spaces, but it is not good practice to do so. It is much better to use an underscore "_" between words, such as: Home_Address. Or you can use something like: HomeAddress.
• Element names cannot be a number, begin with a number or evaluate to a number.

An error-free test of a program in the Program Editor is no guarantee that the program will work as expected - only that it will run. (Sesame won't run a program that won't compile due to syntax errors, and will give you a message to this effect in either Preview or actual Sesame mode.) If you run an updated program in Preview mode (with actual data and so forth) and nothing happens, go back to the Program Editor and text it. If it tests error-free, then it could be that some condition or value it expects from the record(s) you're testing with isn't there.

For more information, see "Using the Programming Editor" in the Sesame Programming Guide.