EXCEPTIONS, ATTRIBUTES, AND REFLECTION in Visual C#.NET

Generator PDF-417 2d barcode in Visual C#.NET EXCEPTIONS, ATTRIBUTES, AND REFLECTION

int main() { try { Console::WriteLine("Outer try"); try { Console::WriteLine("Inner try"); throw gcnew Exception("XYZ"); } catch( Exception^ exception) { Console::WriteLine("Inner catch"); } finally { Console::WriteLine("Inner finally"); } } catch(Exception^ exception) { Console::WriteLine("Outer catch"); } finally { Console::WriteLine("Outer finally"); } } Here is the output of Listing 10-5: Outer Inner Inner Inner Outer try try catch finally finally

The first finally block to execute is the one paired with the last try block to execute. The finally block is a separate scope from the try block, so, for example, any variables declared in the try block aren t available in the finally block. Also, if you created any stack objects, their destructors would be called at the end of the try block and before the finally block executes. Don t try to use jump statements (e.g., continue, break, or goto) to move into or out of a finally block; it is not allowed. Also, you cannot use the return statement from inside a finally block. If allowed, these constructs would corrupt the stack and return value semantics.

A difficult problem in any language is what to do with objects that fail to be constructed properly. When an exception is thrown in a constructor, the result is a partially constructed object. This is not a largely theoretical concern; it s almost always possible for an exception to be thrown in a constructor. For example, OutOfMemoryException could be thrown during any memory allocation. The finalizer will run on such partially constructed objects. In C++, destructors do not run on partially constructed objects. The finalizer is called by the runtime to clean up before the runtime reclaims the memory. As usual, the execution of the finalizer is nondeterministic, so it won t necessarily happen right away, but will happen eventually. This is another reason to write finalizers carefully, without assuming any objects are valid. In Listing 10-6, an exception is thrown in the construction of a member of A in A s constructor. The finalizer is called to clean up; the destructor is not called. Listing 10-6. Throwing an Exception in a Constructor // exceptions_ctor.cpp using namespace System; // the type of the member ref class Class1 { public: Class1() { // Assume a fatal problem has occurred here. throw gcnew Exception(); } }; ref class A { Class1^ c1; Class1^ c2; public: A() { // c1 has a problem; it throws an exception. c1 = gcnew Class1();

// c2 never gets created. c2 = gcnew Class1(); } void F() { Console::WriteLine("Testing F"); } ~A() // Never gets called, even if A is created with stack semantics { Console::WriteLine("A::~A()"); } !A() { // Gets called for partially constructed object Console::WriteLine("A::!A()"); // Don't try to use C2 here without checking for null first. } }; int main() { A a; a.F(); // never reached } This example shows what happens in the simple case of a class without a base class other than Object. In the case where some base classes have already been initialized, the finalizers for any base classes will also execute.

C++/CLI allows you to throw objects that are not in the exception class hierarchy. If you ve done a lot of programming in C# or Visual Basic .NET, this may be somewhat of a surprise, since in those languages, you are limited to throwing exception objects that derive, directly or indirectly, from System::Exception. In C++/CLI, you re not limited in this way. However, if you are calling C++/CLI code from C# or VB .NET code, and an exception object of an unusual type is thrown, it will be wrapped in an exception from the point of view of the C# or VB .NET code. The basic idea is simple, as Listing 10-7 shows. Listing 10-7. Throwing an Object That s Not an Exception // throw_string.cpp using namespace System; public ref class R {