AV or NullReference Exception

In my comments Pavel ask:

How does the CLR decide if a given AV should be converted to a NullReferenceException or not?

Jonathan Keljo the PM in charge of the CLR exception story tells me that in v1 and v1.1, all AV's, regardless of the target address, are converted to NullReferenceExceptions. We had the same concerns that Pavel raises about this, so in a future version we are considering changing this. One idea we are looking into is that CLR will try to look at the target address and make a best effort to use the new AccessViolationException instead of NullReferenceException for the corrupting ones. This can only be a best effort because on some OSes, in some situations, we may not be able to tell (for example Win9x doesn't tell us the address of the bad access).

What do you think? Good idea?

Comments

• Anonymous
  February 26, 2004
  >One idea we are looking into is that CLR will try to look at the target address and make a best effort to use the new AccessViolationException instead of NullReferenceException for the corrupting ones.
  
  I don't see much difference between the two. If some code is handling NullReferenceException, there's a very good chance that it will handle AccessViolationException as well.
  
  In my opinion, access violations that don't look like potential NullReferenceExceptions should be allowed to crash the process.
• Anonymous
  February 27, 2004
  Providing more information via a new exception type seems like a good idea. Although I would think that as long as you work in a language like C# or VB.NET you aren't likely to run into access violations other than those relating to a null reference.
  
  However, MC++ is a different story. I recently got a rather unusual AV exception that indicated an error writing to an address within my DLL's address space. This threw me for a loop for a while until I realized that one of the optimizing options I was using enabled read-only string pooling and some of the code was trying to write over top of a string literal.
  
  Would you make NullReferenceException derive from AccessViolationException since NullReferenceException seems to be a specialization of AVException? It would also be helpful to know whether or not the AV relates to a read or a write but it would probably be good enough to put that info in the message.
• Anonymous
  February 27, 2004
  The comment has been removed
• Anonymous
  February 27, 2004
  Now that CLR provides a new AccessViolationException, what is the guideline of trapping NullReferenceException? Does NullReferenceException still fall under "critical" exception list that people dont put a blanket exception handler on? One thing that I fear would be that people will start trapping NullReferenceException when it is really a AV that should have crashed the app and this can have security implications associated with it.