Beginning REALbasic - From Novice To Professional (2006)

Tackling Multiple Syntax Errors at a Time

If you are working on a relatively large and complex application, you are likely to come across multiple syntax errors at the same time. Rather than addressing them one at a time each time you try to compile your application, REALbasic enables you to configure it to display a list of all the syntax errors it discovers when it attempts to compile your applications. To set this up, click the Edit menu, and then select the Options menu item. This opens the Options window. Next, click the Build Process icon displayed on the left-hand side of the window. REALbasic responds by displaying Build Process settings, as Figure 12-2 shows. Select the Show multiple compile errors option, and then click OK.

Figure 12-2. Configuring REALbasic to display multiple compile errors, as seen on Mac OS X

Once configured, REALbasic displays all the syntax errors it uncovers by adding an Errors screen to the REALbasic IDE, as Figure 12-3 shows. Each syntax error is reported as a separate entry. The data reported includes the type of error, its location within the application, and a descriptive error message. To fix the error, double-click its entry in the Errors screen, and then REALbasic switches over to the code editor and displays the statement where the error resides.

Figure 12-3. Viewing all the syntax errors detected in a REALbasic application, as seen on Mac OS X

Understanding Run-Time Errors

Another type of error you need to look for is run-time errors. Run-time errors occur when an application tries to do something illegal. For example, an OutOfMemoryException run-time error would occur if your application attempts to do something and insufficient memory is available to do so. Likewise, a TypeMismatchException run-time error would occur if a REALbasic application attempts to assign the wrong data type to an object.

Unlike syntax errors, the REALbasic compiler is unable to detect every run-time error. It’s up to you to find and fix them when testing your REALbasic applications. Be careful to test every part of your applications. Otherwise, a seldom-executed function or subroutine might produce a run-time error, which you might miss when testing. As a result, your users would be left to discover your error, which is the last thing a programmer wants to let happen.

If a run-time error occurs when you are testing your application within the REALbasic IDE, REALbasic stops executing the application and flags the error. REALbasic highlights the code statement where the error occurs in the Code Editor and displays a small image of a bug to the left of the code statement, just as it does with syntax errors.

If you fail to discover a run-time error during testing and a user discovers it in the finalrelease version of your application, REALbasic then displays a cryptic error (as Figure 12-4 shows) and immediately terminates the application.

Figure 12-4. REALbasic terminates applications on discovery of a run-time error, as seen on Windows.

Unfortunately, no matter how hard you may try, sometimes it’s impossible to prevent errors from occurring. For example, if your application requires network access to perform a particular task, the network might go down. Likewise, if your application needs to access a particular disk drive on the computer, the disk drive might crash. Fortunately, as you learn in the section “Developing Error Handlers,” you can take steps to help prevent unexpected errors from crashing your applications. By implementing the programming techniques this chapter shows you, you can often add programming logic to your applications that lets them recover from errors or, at the least, enables you to display a user-friendly error message before gracefully terminating application execution.

Understanding Logical Errors

A third category of error you might run into is logical errors. A logical error is caused by a mistake on your part. For example, you might attempt to add two numbers you meant to subtract, resulting in a logically correct, but completely useless, value. Another example of a logical error would be an endless loop.

REALbasic is unable to identify or detect logical errors. Instead, it’s up to you to carefully analyze the output produced by your applications to ensure things are working as they should. The best way to deal with logical errors is to prevent them in the first place by taking the time to carefully plan out your applications.

Working with the REALbasic Debugger

REALbasic’s built-in debugger does a lot more than simply highlight syntax and run-time errors. It provides you with the capability to set breakpoints at specific locations in your application to pause script execution. Once paused, you can track the values assigned to variables, properties, and objects to ensure they contain the values you expect. You can also track the order in which methods are executed to ensure the application’s logical flow is proceeding

in the order you expect. On top of all this, REALbasic lets you exercise line-by-line control over the execution of each statement in your application.

Setting Breakpoints

To set a breakpoint, all you have to do is click the dash located in the first column of the Code Editor, as you see in Figure 12-5. REALbasic identifies breakpoints by displaying a red circular marker. REALbasic automatically pauses application execution at any statement where a breakpoint is set.

Figure 12-5. Setting a breakpoint within a REALbasic application, as seen on Windows

■Note Any breakpoints you set are persistent, meaning they are saved with your REALbasic project and will not go away until you remove them. However, if you compile a stand-alone version of your applications, any embedded breakpoints are ignored.

When debugging your applications, you should add breakpoints in locations where you think errors are most likely to occur. REALbasic enables you to add as many breaks as you think necessary to your application. When you run your application within REALbasic’s IDE and a breakpoint is reached, REALbasic pauses application execution, highlighting the statement containing the breakpoint. The highlighted statement represents the next statement to be executed. At this point, you can review the value of any variables, properties, and objects in your application, as well as take line-by-line control over the execution of your application.

Once you track down and resolve any errors existing within your application, you can remove any breakpoints you set by clicking the red circular marker that represents them or by clicking Projects Clear All Breakpoints.

■Tip As an alternative to setting breakpoints manually via the IDE, you can embed the Break keyword within your code statements. When the compiler reaches a Break keyword, it pauses application execution exactly as if a breakpoint had been manually established.

An advantage to using the Break keyword in place of a breakpoint is you can set up the conditional execution of the Break keyword, as the following shows.

If intCounter > 10 Then

Break

End If

Tracking Values

When either a breakpoint or a Break keyword is reached, the REALbasic compiler pauses the application and displays the Run screen, as shown in Figure 12-6. Using this screen, you can investigate the values assigned to variables, properties, and objects, as well as monitor the logical flow of your application.

The Run screen is divided into two panes. The Code Editor pane, located in the left-hand pane, displays the currently executing method, highlighting the statement containing the breakpoint. Just above the Code Editor pane is the Stack drop-down list, which displays the name of the current method. In addition, you can examine the methods that were executed by the application. The methods are listed in the order they were executed. You can click any method in the drop-down list to display it. By examining the order in which methods are presented in this list, you can review the local flow of your application and make sure things are occurring in the order you expected.

The Variables pane, shown in Figure 12-7, located on the right-hand side of the screen, displays a list of all variables local to the selected method. This provides you with the capability to check the values currently assigned to variables as you debug your application. In addition, the Variables pane is dynamic, meaning the values displayed change as your applications execute.

Any objects displayed in the Variables pane are shown as links. You can click the link to open an object viewer and get more information about the state of the object. For example, Figure 12-8 shows the contents of the object viewer when the Window1 object is selected.

Figure 12-8. You can open a link for an object in the Variables pane to view information about the state of the object.

In addition to inspecting the values assigned to properties that belong to a selected object, you can click a link shown in an object viewer to drill down and view any objects associated with the object. As you can see, starting from the Variables pane, you can drill down and view values associated with any variables, properties, or objects.

■Note The top entry on the Variables pane is always Globals. This link provides you with access to any global variables in your application.

Using Break Points to Control Statement Execution

Once the compiler pauses application execution at a break point, REALbasic provides you with a number of different options for stepping through the execution of your program statements. This way, you have total control over when statements execute, and you can pause to examine the values assigned to variables, properties, and objects, as necessary. To control statement execution, REALbasic provides you with access to a collection of five buttons located at the top of the Run screen, as Figure 12-9 shows.

Figure 12-9. Using the debugger toolbar to control statement execution

■Note You can also access the functionality provided by the Debugger toolbar from the Project menu.

The debugger toolbar on the Run screen consists of the following buttons:

•Pause. Pauses execution without stopping the application and returning to the IDE.

•Stop. Stops execution and exits the debugger.

•Step. Executes the currently selected statement and pauses before executing the next statement. However, if the selected statement is a call to a method, the entire method executes, after which the execution pauses on the next statement.

•Step In. Executes the currently selected statement and pauses before executing the next statement. If the next statement is a call to a method, the debugger displays the statements that make up the methods and lets you step through them line-by-line.

•Step Out. Executes the rest of the statements in a method without pausing for line-by- line execution. This lets you skip a step-by-step execution of code statements within methods you believe are bug free to speed the debug process.

As you use the Step, Step In, and Step Out buttons to control statement execution, the compiler continues to identify the next statement to be executed by highlighting it. In addition, you can resume normal application execution at any time by clicking the Resume button located on REALbasic’s main toolbar.

Developing Error Handlers

As previously discussed, run-time errors (or exceptions) happen for many different reasons. If these errors are not handled, your REALbasic applications display cryptic errors and crash. This can leave your users confused and frustrated.

REALbasic provides you with different ways to trap errors and prevent them from wreaking havoc on your application. To develop exception handlers, you need to be able to anticipate the locations within your applications where run-time errors are most likely to occur. Likely candidate locations include anyplace within your applications where you accept freeform user input, as well as anywhere you access computer and network resources, which are subject to failure or temporary periods of unavailability.