I get to take time away from consulting work and teach our .NET ESSENTIALS class from time to time. On the first day most students will hear me utter the words “its not possible to know every class in the .NET framework”, and I pretty much think that it is true, except for perhaps Brad Abrams who did excellent work with the SLAR.

It is however just a theory, and theories need to be tested to see if they are true – but how do I test it? Well I’ve decided to walk the framework, from top to bottom to see how much information I can retain. Back when I was teaching myself about .NET in 2000 I would pick a namespace each night and understand as much about it as I could.

My hope is that by going much deeper I’ll not only learn a lot about the classes in the Framework but also get insights into the runtime itself. Logically features in the runtime eventually have to manifest themselves in the Framework so there should be lots to learn.

On my journey I’ll post up anything interesting I find. First stop? System.AccessViolationException.

So why is an exception class interesting? Well for starters AccessViolationException is new in the .NET Framework 2.0 and its designed to replace the use of a NullReferenceException in some instances.

If you’ve ever written any interop code before (especially P/Invoke where you are dealing with pointers) you may have gotten strange NullReferenceException errors – looking at the code you can’t see where but when you debug you notice that its coming out of a member that ultimately does an interop call.

Well in .NET 1.x this could be an indication that the memory that the pointer refers to never was or is no longer allocated to the program and the runtim doesn’t know how to deal. Unfortunately NullReferenceException doesn’t really describe the problem – presumably thats what this new exception is all about, making the problem easier to spot.

Now when you get this error its a bug in your code, pure and simple so you should really crash the application if possible but if for the sake of argument you had a .NET 1.x application which happened to detect this condition and work around it, the change to AccessViolationException would mean that .NET 2.0 has introduced a breaking change.

Fortunately the guys at Microsoft have thought about this and have introduced a configuration setting which you can slap in the <runtime /> section of the application configuration file.

<LegacyAccessViolationPolicy enabled=”1” />

Now – what else have I noticed? Well AccessViolationException ultimately derives from System.Exception and if you look closely you can see that in .NET 2.0 it has been given a new property called Data which is an IDictionary. I guess the idea here is that you can provide additional information when you throw exceptions without having to create a new type of exception.

Where this might be useful is when you have an exception defined for your particular component but when you throw it you want to pass back all the interesting variables that are in scope at the time. This really makes exceptions a bit more useful for fault finding without having to write a lot of exception classes for each condition – it guess thats a good thing . . .