Datasheet

The architecture of exception handling also provides a convenient means to pass an object containing
precise details of the exception condition to an exception handling routine. This object might include an
appropriate message for the user and details of exactly where in the code the exception was detected.
Most exception handling architecture, including the control of program flow when an exception occurs,
is handled by the high-level languages (C#, Visual Basic 2005, C++), and is not supported by any special
IL commands. C#, for example, handles exceptions using
try{}, catch{}, and finally{} blocks of
code. (For more details, see Chapter 12.)
What .NET does do, however, is provide the infrastructure to allow compilers that target .NET to sup-
port exception handling. In particular, it provides a set of .NET classes that can represent the exceptions,
and the language interoperability to allow the thrown exception objects to be interpreted by the excep-
tion handling code, irrespective of what language the exception handling code is written in. This lan-
guage independence is absent from both the C++ and Java implementations of exception handling,
although it is present to a limited extent in the COM mechanism for handling errors, which involves
returning error codes from methods and passing error objects around. The fact that exceptions are han-
dled consistently in different languages is a crucial aspect of facilitating multi-language development.
Use of Attributes
Attributes are a feature that is familiar to developers who use C++ to write COM components (through
their use in Microsoft’s COM Interface Definition Language [IDL]). The initial idea of an attribute was that
it provided extra information concerning some item in the program that could be used by the compiler.
Attributes are supported in .NET— and hence now by C++, C#, and Visual Basic 2005. What is, however,
particularly innovative about attributes in .NET is that a mechanism exists whereby you can define your
own custom attributes in your source code. These user-defined attributes will be placed with the meta-
data for the corresponding data types or methods. This can be useful for documentation purposes, where
they can be used in conjunction with reflection technology in order to perform programming tasks based
on attributes. Also, in common with the .NET philosophy of language independence, attributes can be
defined in source code in one language, and read by code that is written in another language.
Attributes are covered in Chapter 11, “Reflection.”
Assemblies
An assembly is the logical unit that contains compiled code targeted at the .NET Framework. Assemblies are
not covered in great detail in this chapter because they are covered in detail in Chapter 15, “Assemblies,”
but we summarize the main points here.
An assembly is completely self-describing, and is a logical rather than a physical unit, which means that
it can be stored across more than one file (indeed dynamic assemblies are stored in memory, not on file
at all). If an assembly is stored in more than one file, there will be one main file that contains the entry
point and describes the other files in the assembly.
Note that the same assembly structure is used for both executable code and library code. The only real
difference is that an executable assembly contains a main program entry point, whereas a library assem-
bly doesn’t.
17
.NET Architecture
05_575341 ch01.qxd 10/4/05 7:03 PM Page 17