13.1 Debugging Flash Remoting Applications

Flash is a complex environment, and
adding Flash Remoting to the equation only increases the complexity.
You must contend not only with the visual aspects of your Flash movie
and the underlying ActionScript, but also the server-side code, the
database code, and the HTTP connections. There are quite a few pieces
that make up the client/server environment of a Flash Remoting
application, and quite a few places where your application can go
wrong. Debugging a Flash Remoting application involves complex
interaction between all of these environments, as well as the ability
to separate the parts of the application so that they can be examined
without the added burden of the sum of all the parts. Refer to the
best practices offered in Chapter 12 for ways to
isolate the various portions of your program to ease development and
testing.

13.1.1 Types of Errors

Errors in any programming environment can be divided into
several logical categories (although see "Error
Types" in Chapter 3 for
additional discussion of potential sources of errors):

Syntax errors

Errors caused by
incorrect
use of code. This could be a simple use of a programming construct in
the wrong way, or using some programming construct that
doesn't exist in ActionScript. These are usually
caught at compile time. Previewing in Flash is
considered compile time.

Typographical errors

Errors caused by simply mistyping a piece of code. Color
coding is a big help in finding these types of errors; many times a
misspelled keyword does not have the correct color coding on it,
which is a dead giveaway that something is rotten. These errors are
occasionally caught at compile time, but the more insidious ones can
slip through if they are otherwise valid code.

Logical errors

Errors caused by improper logic in your code. These are often the
insidious errors that don't cause a total failure of
the application, but instead introduce errors in program results or
introduce only occasional errors. Intermittent bugs are often the
hardest to detect and solve. They are hard to detect because they
happen only under certain conditions, which may be hard to reproduce.
They are hard to solve because if you can't reliably
reproduce a bug in the first place, you can't
confirm that your fixes have solved the problem.

All of these errors can be tracked down through the debugging
process. Many times, having someone else look at your code can help
you more than hours spent debugging alone. The fresh set of eyes can
spot a problem that you have missed or don't realize
is a problem. You can use a coworker or post a problem piece of code
to a support newsgroup or forum. Getting this far, however, means
that you know where the problem lies. Many times, this is not the
case.

A bug can occur in any of these areas, but to find the bug you have
to know where to look and how to look for it. The Flash authoring
environment provides many of the tools that will help you pinpoint a
problem, but it is only the messenger; the error messages can help
you determine where to look for the real problem.

Beginners often flounder with guesses and suppositions, while
experienced developers rely on their debugging tools. For Flash
Remoting applications, you can start you investigation with the
NetConnection Debugger panel, as discussed in this chapter. Of
course, to use any debugger effectively, you must have the
foundational knowledge of the technology (which you should have after
getting this far in the book) and you must have some knowledge of
what component of the application performs a particular task. This
might sound a bit simplistic, but people coming from Flash-only
backgrounds often have trouble determining where a particular error
is occurring, such as on the server. (This is doubly true if you are
not the original developer of part or all of the application.) For
example, a typical error message might look like this:

"Error connecting to Northwind"

What does it mean? The reason for the error could be, but is not
limited to, one of the following:

Bad username or password

No database driver

Wrong database driver

Wrong format for connection string

Bad server-side code calling the database

No permission to access a database object, such as a table or stored
procedure

Therefore, one of the keys to being able to pinpoint problems is
knowing what does what. You must be able to track the logical
progression of your code to determine where the error originates. As
with most error messages, there are several different reasons why the
error may be occurring. A little detective work may be involved:

If your ActionScript code is passing anything to the database, you
can start there.

If not, look at your server-side code. The error could be a mistyped
piece of code or connection string.

You can also try logging on to your database directly and executing
the code from there; many users log themselves on as an administrator
when developing an application, only to find out that the permission
levels they are using in an application are not working for all
objects. Database servers like SQL Server allow you to set individual
permission levels for each object. Make sure the permission levels
are correct for the query you are running.

If you are running a file-based database like Microsoft Access, make
sure your web server has the appropriate permissions to access the
database file.

All of these different error situations can be tracked down with a
little bit of know-how and some digging. The Flash environment
contains two debuggers to aid in this detective work?the Flash
ActionScript interactive debugger and the NetConnection debugger. The
ActionScript debugger is always available during authoring by
choosing Ctrl Debug Movie (or if you're
already testing the movie, it's Window
Debugger). The NetConnection debugger is used for Flash Remoting. To
activate the NetConnection debugger during authoring, include the
NetDebug.as file in your Flash movie. This
allows the NetConnection Debugger panel to become active and report
problems as they arrive from the server.

13.1.3 Consistency

One of the best ways to avoid extensive
debugging
periods is to write your code with consistency. This includes such
things as coding styles and conventions, variable naming conventions,
comments and documentation, and readability. The important thing is
not which convention you decide on, but that you stick to a
convention. For example, some people prefer to format their loops
like this:

for (i=0; i < 10; i++)
{
print("something");
}

This is a perfectly acceptable convention, as is this (which we use
in this book to save vertical space):

for (i=0; i < 10; i++) {
print("something");
}

I find that the second approach makes it easier to spot bugs like
this, in which the semicolon ends the for loop
unintentionally:

for (i=0; i < 10; i++); {
print("something");
}

I find such bugs harder to spot when code is formatted like this:

for (i=0; i < 10; i++);
{
print("something");
}

Consistency in variable naming is also important to debugging. If you
have a convention of capitalizing the first letter in each word
(except the first word), don't deviate from that in
your code:

myFirstName = "Tom";
myLastName = "Muck";
myZIP = "22193";

The last variable does not follow my capitalization convention, so I
might be prone to write it like this elsewhere in the code:

myZip = "22193";

In ActionScript 1.0 (when played in Flash Player 6), the case
difference does not matter (at least with regard to variable names),
and myZIP and myZip refer to
the same variable. In other languages, like ActionScript 2.0,
Server-Side ActionScript, ECMAScript, Java, or C#,
myZIP and myZip refer to
different variables, which could be difficult to debug. ActionScript
1.0 is also strictly case-sensitive when developed in Flash 2004 or
Flash Pro and exported in Flash Player 7 format. See Reference Guide
ActionScript Basics Syntax Case
Sensitivity in the Flash 2004 and Flash Pro Help window for details.

Spacing is another key issue in writing code. Whitespace is in many
ways just as important as the actual code; without whitespace, your
code is unreadable. Consider this query:

It's not very pretty, and it's not
easy to spot where the bug is, or even if there is a bug. The query
is supposed to retrieve all customers from the USA having at least
five items in their order. When you run the query on the
Northwind database, you get about 12 results.
After reformatting the query with whitespace for readability, you
spot the error more easily:

Now the query returns three results, which is correct. Queries are
much easier to debug when you write them clearly with whitespace. The
first query might have taken a long time to debug, yet I have seen
plenty of cases where people write their queries like this.

Commenting your code is extremely important as well. Sometimes, a
well-placed comment can alert you to a bug in the code that you would
normally not spot immediately. If the preceding query had included
the following comment, containing the word
"order," a trained developer would
realize the order ID was missing from the GROUP BY
clause:

-- Get all US orders that have more than 5 items

13.1.4 Feature Creep

Why is feature creep being discussed in a chapter
about debugging and testing? Most projects have a plan in place that
specifies exactly what the application will do and how it will do it.
Feature creep happens when you don't stick to the
plan. During the debugging and testing phase, adding a new feature
increases the likelihood of new bugs being introduced into the
application, causing delays in the entire process. For this reason it
is usually best to note the new features and implement them in the
next version of your software, rather than try to get them into the
current version.