First, let's define a "bad thing": anything that happens that I didn't expect to happen. With regards to programming, these come in two flavors:
- compile-time errors and;
- run-time errors.
Let's look at a couple examples of each and how to rectify them.
Compile-Time Errors
When a compiler, including the C# compiler, can't interpret what you're attempting to convey, it will print an error message and your application will fail to build. Type the following code into a file named HelloErrors.cs, and compile it: -
using Syste;
class HelloErrors
{
public static void Main()
{
xConsole.WriteLine("Hello, World");
Console.WriteLinex("Hello, World");
}
}
Running the compiler will result in this output: -
HelloErrors.cs(1,7): error CS0234: The type or namespace name ' Syste' does not exist in the class or namespace ''
Keeping in mind that there's always a default, global namespace, this means that the compiler could not locate anything called Syste, for obvious reasons. However, what I want to illustrate here is what to expect when the compiler encounters syntax errors in your code. First you'll see the name of the current file being compiled, followed by the line number and column position of the error. Next you'll see the error code as defined by the compiler-in this case, CS0234.
Finally, after the error code, you'll see a short description of the error. Many times, this description will give you enough to make the error clear. However, if it doesn't, you can search for the error code in the .NET Framework SDK Documentation, which is installed with the .NET Framework SDK, for a more detailed description. The online help associated with the CS0234 error code is shown in Figure 3-3.
Figure 3-3 You can use the error code supplied by the C# compiler to find a description of the error in the online help documentation.-
Notice that although we introduced three errors-the System namespace is misspelled, the Console class is misspelled, and the call to the WriteLine method is misspelled-the compiler will report only one error. This is because certain errors, once they are encountered, cause the compiler to abort the compilation process and print the errors accrued up to that point. In this example, the compiler stopped its compilation process once it could not resolve the using directive because that error could be the cause of many more errors. Once you've correctly spelled the System namespace in the using directive, the compiler will report the line numbers and column positions of the remaining two errors.
Spelunking with ILDASM
As you read in Chapter 2, when you create an EXE or a DLL by using a .NET compiler, the file is not your ordinary executable. Instead, it comprises a manifest, which lists the types and classes included in the file, and MSIL (Microsoft intermediate language) opcodes that are later compiled and executed by your installation application or the .NET runtime using a just-in-time compiler (JITter).
One huge advantage of this is that the generated MSIL looks like assembly language and can be used as an incredible teaching tool to illustrate what the compiler has done with our code. For this reason, many times in this tutorial I'll "drop down" to the C# compiler's MSIL output to illustrate how something works under the covers or to explain why you should use a particular feature of the language in a specific manner. To see the MSIL output by the .NET compilers, Microsoft has included a disassembler named the Microsoft .NET Framework IL Disassembler (ILDASM) to enable you to open a .NET executable file (EXE or DLL) and peruse its namespaces, classes, types, and code. We'll begin getting comfortable with ILDASM in the next section.