CINEMA 4D, Revision 6

COFFEE plugin tutorial
Programming basics

coffee tutorial 1:  Introduction
coffee tutorial 2:  Programming basics
coffee tutorial 3:  The nuts and bolts of a plugin
coffee tutorial 4:  Your first dialog box
coffee tutorial 5:  A better dialog box
coffee tutorial 6:  Creating a house object
coffee tutorial 7:  Interactive house modeling
coffee tutorial 8:  International resources

Program errors

Pest controller

For historical reasons, the whole process of finding and removing program errors is referred to as "debugging".

Powerful programming environments have debugger programs that enable you to run the program one step at a time, i.e. one command at a time. Here you can keep track of things as the program runs and you can check the content of variables at any time.

Unfortunately C.O.F.F.E.E. doesn't have a debugger. Instead you have to use blackbox programming: you program some code, check if it works and if it doesn't, you'll have to guess what could be going wrong inside that black box because you can't see inside it. It's not quite as bad as that though, because there are little tricks that can make life easier. For example, a classic trick is simply to print out the content of important variables in key places of the code. e.g.

println(vXYZ);

prints the content of the varial vXYZ in the Console window. If the content is printed out, it tells you that a) your program works up to that point b) what the content of the variable is at that point. Here's a general example.

I send Luigi out on his moped to deliver a pizza to the third street, fifth house, seventh floor, ninth room. A while later, the phone rings and Luigi says: "There's no ninth room". This is the error message, if you like. It tells me the effect of an error, but not exactly what caused it. I don't know if I sent Luigi to the wrong street, the wrong house, the wrong floor or the wrong room. Even so, at least it's a starting point. I know there is something wrong with that address and I can check all the relevant details.

Returning from our pizza to our program, there are in fact several distinct types of error.

Typing errors

These are usually recognized by the computer and you'll be told about it, e.g. error line 17, 5th character, brace expected.

However, the error does not necessarily have to be in the line reported! Perhaps a semicolon is missing from the previous line and that has led to the compiler thinking it's the next line that is wrong. Typing errors that the compiler cannot pick up on are e.g. the assignment of incorrect names.

Run-time errors

These dreaded errors come to light only when you run the program. e.g.

Variable A=5; Variable B=7; Variable C=A/B;

Here, no error is obvious. However, if the variable B is set to null while the program runs, the program will attempt to divide by null. This is not allowed and leads to a run-time error!

Individual routines work; the sequence Routine1, Routine2, Routine3 is fine; Routine3, Routine3, Routine1 is fine too, but perhaps you get a run-time error with the combination Routine2, Routine1. It's just not possible to test each and every conceivable combination. For this reason, although you can test for errors, you can't test for their absence.

Never tempt fate by claiming that your program is bug-free!

Logical errors

These aren't really errors as such because the program still runs and produces results. It's just that the results are incorrect and so there must be a mistake in the way the programmer made the calculations. Logical errors can sometimes take days to isolate because the program code itself is completely valid. The programmer may go through the listing several times and be convinced there is nothing wrong with the logic. Then all of a sudden the programmer blushes and finds the little mistake that causes the miscalculation and all is well again.

An important weapon in your arsenal for finding errors is the beta tester. Only a stranger to the code can be relied upon to tinker here and there and try things you hadn't even thought of. A hint where something is wrong is all the experienced programmer usually needs to recognize and remove the problem. Unfortunately it's always possible that you'll create a new error while you correct the old one!

System errors

The world is bigger than just our program. The plugin must fit into an environment, which can change dramatically to produce errors that are beyond our control. For example, perhaps our program will stop working with the next version of the operating system or the next version of the main application. In these circumstances, the programmer can feel a great deal of pressure to provide a fix, even though strictly speaking he or she is blameless.

Program structure

Even program listings have aesthetic issues! A "pretty" listing works. A program with a confusing listing is likely to generate errors.

Variables

I recommend you define variables at the start rather than the middle of a listing. Strictly speaking, you don't have to do this, but it keeps the code tidy and easier to digest.

function fXYZ()
{ var a,b,c;
  //
  ...
}

Braces

You'll often see listings in this style:

if (a==b) {
  do this;
}

I always write braces directly under one other. That way I can soon tell if the number of open braces equals the number of close braces plus I can see clearly where each block starts and ends. Clarity becomes even more important once your listings become deeply nested.

if (a==b)
{ do this;
}