Programming in C - Dealing with Errors
(Page 4 of 9 )
To err is human, so there’s no need to be embarrassed about making mistakes. Fortunately, computers don’t generally make mistakes themselves and they’re actually very good at indicating where we’ve slipped up. Sooner or later your compiler is going to present you with a list (and sometimes a list that’s longer than you want) of the mistakes that are in your source code. You’ll usually get an indication of the statements that are in error. When this happens, you must return to the editing stage, find out what’s wrong with the incorrect code, and fix it. Keep in mind that one error can result in error messages for subsequent statements that may actually be correct. This usually happens with statements that refer to something that is supposed to be defined by a statement containing an error. Of course, if a statement that defines something has an error, then what was supposed to be defined won’t be.
Let’s step through what happens when your source code is incorrect by creating an error in a program. Edit your second program example, removing the semicolon (;) at the end of the line with printf() in it, as shown here:
/* Program 1.2 Your Second C Program */
#include <stdio.h>
void main() {
printf("If at first you don\'t succeed, try, try, try again!")
}
If you now try to compile this program, you’ll see an error message that will vary slightly depending on which compiler you’re using. A typical error message is as follows:
Syntax error : missing ';' before '}' HELLO.C - 1 error(s), 0 warning(s)
Here, the compiler is able to determine precisely what the error is, and where. There really should be a semicolon at the end of that printf() line. As you start writing your own programs, you’ll probably get lots of errors during compilation that are caused by simple punctuation mistakes. It’s so easy to forget a comma or a bracket, or to just press the wrong key. Don’t worry about this: lots of experienced programmers make exactly the same mistakes—even after years of practice.
As I said earlier, just one mistake can sometimes result in a whole stream of abuse from your compiler, as it throws you a multitude of different things that it doesn’t like. Don’t get put off by the number of errors reported. After you consider the messages carefully, the basic approach is to go back and edit your source code to fix what you can, ignoring the errors that you can’t understand. Then try to compile the source file again. With luck, you’ll get fewer errors the next time around.
To correct your example program, just go back to your editor and reenter the semicolon. Recompile and check for any other errors, and your program is fit to be run again.
Dissecting a Simple Program Now that you’ve written and compiled your first program, let’s go through another that’s very similar and see what the individual lines of code do. Have a look at this program:
/* Program 1.3 Another Simple C Program - Displaying a Quotation */
#include <stdio.h>
void main() {
printf("Beware the Ides of March!"); }
This is virtually identical to your first program. Even so, you could do with the practice, so use your editor to enter this example and see what happens when you compile and run it. If you type it in accurately, compile it, and run it, you should get the following output:
Beware the Ides of March!
Comments Look at the first line of code in the preceding example:
/* Program 1.3 Another Simple C Program - Displaying a Quotation */
This isn’t actually part of the program code, in that it isn’t telling the computer to do anything. It’s simply a comment, and it’s there to remind you, or someone else reading your code, what the program does. Anything between /* and */ is treated as a comment. As soon as your compiler finds /* in your source file, it will simply ignore anything that follows until it finds the matching */ that marks the end of the comment. This may be on the same line, or it can be several lines further on. Whatever is between /* and */ will be completely ignored by the compiler, even if it looks like program code.
You should try to get into the habit of documenting your programs, using comments as you go along. Your programs will, of course, work without comments, but when you write longer programs you may not remember what they do or how they work. Put in enough comments to ensure that, a month from now, you (and any other programmer) can understand the aim of the program and how it works.
As I said, comments don’t have to be in a line of their own. A comment is everything between /* and */, wherever /* and */ are in your code. Let’s add some more comments to the program:
/* Program 1.3 Another Simple C Program - Displaying a Quotation */
#include <stdio.h> /* This is a preprocessor directive */ void main() /* This identifies the function main() */ { /* This marks the beginning of main() */
printf("Beware the Ides of March!"); /* This line displays a quotation */ } /* This marks the end of main() */
You can see that using comments can be a very useful way of explaining what’s going on in the program. You can place comments wherever you want in your program, and you can use them to explain the general objectives of the code as well as the specifics of how the code works. You can also use comments to identify the author of the code and to assert your copyright if you wish.
Preprocessing Directives Look at the following line of code:
#include <stdio.h> /* This is a preprocessing directive */
This isn’t strictly part of the executable program, but it is essential in this case—in fact, the program won’t work without it. The symbol # indicates this is a preprocessing directive, which is an instruction to your compiler to do something before compiling the source code. The compiler handles these directives during an initial preprocessing phase before the compilation process starts. There are quite a few preprocessing directives, and they’re usually placed at the beginning of the program source file.
In this case, the compiler is instructed to “include” in your program the contents of the file stdio.h. This file is called a header file, because it’s usually included at the head of a program. It defines information about some of the functions that are provided by the standard C library. The header file will contain C source code and other preprocessor directives. In this case, as you’re using the printf() function from the standard library, you have to include the stdio.h header file. This is because stdio.h contains the information that the compiler needs to understand what printf() means, as well as other functions that deal with input and output. All header files in C have file names with the extension .h. You’ll use other C header files later in the book.
NOTE It’s common practice to write the header file names in the #include directive in lowercase letters.
Every C compiler that conforms to the American National Standards Institute (ANSI) standard for the language will have a set of standard header files supplied with it. Header files primarily contain definitions relating to standard library functions that are available with C. Although all ANSI standard C compilers will support the same set of standard library functions and will have the same set of standard header files available, there may be extra library functions provided with a particular compiler that may not be available with other compilers.
Defining the main() Function The next four statements define the function main():
void main() /* This identifies the function main() */
{
| /* This marks the beginning of main()
| */
|
| printf(“Beware the Ides of March!”); /* This line displays a quotation
| */
|
}
| /* This marks the end of main()
| */
|
A function is just a named block of code between braces that carries out some specific set of operations. Every C program consists of one or more functions, and every C program must contain a function called main()—the reason being that a program will always start execution from the beginning of this function. So imagine that you’ve created, compiled, and linked a file called progname.exe. When you execute this program, it causes the function main() for the program to be called.
The first line of the definition for the function main() is as follows:
void main() /* This identifies the function main() */
This defines the start of the function main(). Notice that there is no semicolon at the end of the line. The first line identifying this as the function main() has the keyword void at the beginning. What appears here defines the type of value to be returned by the function. The keyword void signifies that the function main() returns no value.
There are circumstances in which you would want to return something from main() to the operating system—an error code, for example. In those situations, a keyword other than void would be used. I’ll cover this in a later chapter.
The parentheses that immediately follow the name of the function, main, enclose a definition of what information is to be transferred to main() when it starts executing. In this example, however, you can see that there’s nothing between the parentheses, so no information can be transferred. Later, you’ll see how information is transferred to main() and to other functions in a program. In general, the function main() can call other functions that, in turn, may call further functions, and so on. For every function that’s called, you have the opportunity to pass some information to it within the parentheses that follow its name.
 This article is excerpted from Beginning C by Ivor Horton (Apress, 2004; ISBN 1590592530). Check it out at your favorite bookstore today. Buy this book now. |
Next: Keywords >>
More Code Examples Articles
More By Apress Publishing
/ 37 
