Chris Brumme - How about a type-specific try-catch mechanism for Intellisense?

I think this is a thing that third-party developers could step up and tackle (well, maybe not the intellisense bits, but who knows - VSIP seems pretty extensive...).  It would be just like the new permcalc tool we heard about - walk through the MSIL looking for throw instructions then trace back down to see the type of the object they threw.  It would only get tricky if the code was doing something strange like create an exception and then throw it later on inside a loop or something.  Tricky at parts, but extremely doable.  And once we can query a method to see what it throws, then we could just use reflection to blast through all the public and protected members of the framework and get a list of what everything throws for sure.  Hey, we could even spit the list out in XML! =P

I found out when using java (long time ago) that type-specific exceptions were a bit an overkill specially when you have to follow guidelines and implement an specific design. I end up using the "throws" keyword everywhere and only taking care of exceptions that were expected from the design itself.
I must say that i do not miss it when using .NET at all.

I haven't use Java however I can see that checked exceptions might be a bit too much of a versioning hassle.  OTOH the concept does appeal to my meticulous side.  I think the concept of a non-enforced checked exception (perhaps a better name is "documented exceptions") is a good idea.  I have run into exceptions in shipping code that weren't documented in the MSDN docs!  So even though I thought I was handling everything, I wasn't. And the real drag of it all was that it wasn't a fatal exception.  It was something, that if I had caught it I could have put a message to the user that they needed to re-install/repair in order to use a particular feature. I am also intrigued by the concept of slicing exceptions in a different fashion besides inheritance hierarchy. I have always thought the .NET exception hierarchy could be better.  There are some exceptions that inherit directly from System.Exception. Other inherit from the vestigial System.ApplicationException. And worse, it is not easy to tell which exceptions should only be thrown by the runtime like System.NullReferenceException or System.IndexOutOfRangeException. I still occassionally catch folks throwing those exceptions rather than the ones deriving from System.ArgumentException. Perhaps all the runtime exceptions should implement an attribute or marker interface like IFatalException or IRuntimeError or something like that.