Very cool.
I noticed the <exception> field in the XML portion of the method description
when documenting methods and wondered if that would ever make it to
intellisense. I've long believed that exceptions should be treated as 1st
class citizens.
Now I've a question for anyone interested: this allows us to document
exceptions that are specifically thrown by a method but there are two use
cases that this does not cover and I'd like to hear how others would handle
this. The cases are:
1. The method swallows all exceptions so that nothing that it does not throw
itself can be caught by the caller. In many cases no exceptions at all are
allowed to escape. In code terms...
void SomeMethod()
{
try{ //...code }
catch{} // swallows everything
}
2. The method does not swallow any exceptions so that anything that is
thrown can be caught by the caller. In code terms...
void SomeMethod()
{
}
There is obviously a spectrum here but I believe this represents two of the
boundary conditions. Thoughts?
"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:ex****************@tk2msftngp13.phx.gbl...
Some of you guys (particularly the MVPs) are already aware of this, but
i'll post for the others who might not have seen it and might be interested
(btw - sorry for being absent for so long).
A while back there was a long discussion about checked exceptions and
expected exception lists. I couldn't say much because of the NDA, but MS
officially released some news on it a few months ago. While writing code,
catch statements will now display an intellisense list of known
exceptions. Of course, this assumes the author documented the code.
Happy coding!
-Rob Teixeira [MVP]
