Exception Types

Exception Types

Chapter 10 mentioned some of the exception types that can be thrown during the execution of IL instructions. Earlier chapters mentioned some of the exceptions thrown by the loader and the JIT (just-in-time) compiler. Now it’s time to review all these exceptions in an orderly manner.

All managed exceptions defined in the .NET Framework classes are descendants of the [mscorlib]System.Exception class. This base exception type, however, is never thrown by the common language runtime. In the following sections, I’ve listed the exceptions the runtime does throw, classifying them by major runtime subsystems. Enjoying the monotonous repetition no more than you do, I’ve omitted the [mscorlib]System. part of the names, common to all exception types. As you can see, many of the exception type names are self-explanatory.

Loader Exceptions

The loader represents the first line of defense against erroneous applications, and the exceptions it throws are related to the file presence and integrity.

  • AppDomainUnloadedException

  • CannotUnloadAppDomainException

  • BadImageFormatException  Corrupt file headers or segments that belong in read-only sections (such as the runtime header, metadata, and IL code) are located in writeable sections of the PE file.

  • ArgumentException  This exception is also thrown by the JIT compiler and the interoperability services.

  • Security.Cryptography.CryptographicException

  • FileLoadException

  • MissingFieldException

  • MissingMethodException

  • TypeLoadException  This exception, which is most frequently thrown by the loader, indicates that the type metadata is illegal.

  • UnauthorizedAccessException  A user application is attempting to directly manipulate the system assembly Mscorlib.dll.

  • OutOfMemoryException  This exception, which is also thrown by the execution engine, indicates memory allocation failure.

JIT Compiler Exceptions

The JIT compiler throws only two exceptions. The second one can be thrown only when the security services are engaged.

  • InvalidProgramException  This exception, which is also thrown by the execution engine, indicates an error in IL code.

  • VerificationException  This exception, which is also thrown by the execution engine, indicates that IL code verification has failed.

Execution Engine Exceptions

The execution engine throws a wide variety of exceptions, most of them related to the operations on the evaluation stack. A few exceptions are thrown by the thread control subsystem of the engine.

  • ArithmeticException

  • ArgumentOutOfRangeException

  • ArrayTypeMismatchException  This exception is also thrown by the interoperability services.

  • DivideByZeroException

  • DuplicateWaitObjectException

  • ExecutionEngineException  This is the generic exception, indicating that some sequence of IL instructions has brought the execution engine into a state of complete perplexity—as a rule, by corrupting the memory. Verifiable code cannot corrupt the memory and hence does not raise exceptions of this type.

  • FieldAccessException  This exception indicates, for example, an attempt to load from or store to a private field of another class.

  • FormatException

  • IndexOutOfRangeException

  • InvalidCastException

  • InvalidOperationException

  • MethodAccessException  This exception indicates an attempt to call a method to which the caller does not have access—for example, a private method of another class.

  • NotSupportedException

  • NullReferenceException  This exception indicates an attempt to dereference a null pointer (a managed or unmanaged pointer, or an object reference).

  • OverflowException

  • RankException  This exception is thrown when a method specific to an array is being called on a vector instance.

  • RemotingException

  • Security.SecurityException

  • StackOverflowException

  • Threading.SynchronizationLockException This exception is thrown when an application tries to manipulate or release a lock it has not acquired—for example, by calling the Wait, Pulse, or Exit method before calling the Enter method of the [mscorlib]System.Threading.Monitor class.

  • Threading.ThreadAbortException

  • Threading.ThreadInterruptedException

  • Threading.ThreadStateException

  • Threading.ThreadStopException

  • TypeInitializationException  This exception is thrown when a type—a class or a value type—failed to initialize.

Interoperability Exceptions

The following exceptions are thrown by the interoperability services of the common language runtime, which are responsible for managed and unmanaged code interoperation:

  • DllNotFoundException  This exception is thrown when an unmanaged DLL specified as a location of the unmanaged method being called cannot be found.

  • ApplicationException

  • EntryPointNotFoundException

  • InvalidComObjectException

  • Runtime.InteropServices.InvalidOleVariantTypeException

  • MarshalDirectiveException  This exception is thrown when data cannot be marshaled between managed and unmanaged code in the specified way.

  • Runtime.InteropServices.SafeArrayRankMismatchException

  • Runtime.InteropServices.SafeArrayTypeMismatchException

  • Runtime.InteropServices.COMException

  • Runtime.InteropServices.SEHException  This is the generic managed exception type for unmanaged exceptions.

Subclassing the Exceptions

In addition to the plethora of exception types already defined in the .NET Framework classes, you can always devise your own types tailored to your needs. The best way to do this is to derive your exception types from the “standard” types listed in the preceding sections.

The following exception types are sealed and can’t be subclassed. Again, I’ve omitted the [mscorlib]System. portion of the names.

  • InvalidProgramException

  • TypeInitializationException

  • Threading.ThreadAbortException

  • StackOverflowException

    caution

    As mentioned earlier, I must warn you against devising your own exception types not derived from [mscorlib]System.Exception or some other exception type of the .NET Framework classes.

Unmanaged Exception Mapping

When an unmanaged Win32 exception occurs within a native code segment, the execution engine maps it to a managed exception that is thrown in its stead. The different types of unmanaged exceptions, identified by their status code, are mapped to the managed exceptions as described in Table 11-3.

Table 11-3  Mapping Between the Managed and Unmanaged Exceptions

Unmanaged Exception Status Code

Mapped to Managed Exception

STATUS_FLOAT_INEXACT_RESULT

STATUS_FLOAT_INVALID_OPERATION

STATUS_FLOAT_STACK_CHECK

STATUS_FLOAT_UNDERFLOW

ArithmeticException

ArithmeticException

ArithmeticException

ArithmeticException

STATUS_FLOAT_OVERFLOW

STATUS_INTEGER_OVERFLOW

OverflowException

OverflowException

STATUS_FLOAT_DIVIDE_BY_ZERO

STATUS_INTEGER_DIVIDE_BY_ZERO

DivideByZeroException

DivideByZeroException

STATUS_FLOAT_DENORMAL_OPERAND

FormatException

STATUS_ACCESS_VIOLATION

NullReferenceException

STATUS_ARRAY_BOUNDS_EXCEEDED

IndexOutOfRangeException

STATUS_NO_MEMORY

OutOfMemoryException

STATUS_STACK_OVERFLOW

StackOverflowException

All other status codes

Runtime.InteropServices.SEHException



Inside Microsoft. NET IL Assembler
Inside Microsoft .NET IL Assembler
ISBN: 0735615470
EAN: 2147483647
Year: 2005
Pages: 147
Authors: SERGE LIDIN

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net