How about intellisense in Whidbey that looks at the exceptions a called function may raise. I really hate having to look in the documentation everytime to make sure I'm catching all relavent expections. Perhaps this feature could be added to the code refactoring "Surround with Try block" stuff. So it would add the specific exception catchs (not just Exception).
Sounds like a great idea. Even if there was some indication of what exceptions might be raised at a specific point would be a great help. To have intellisense build cautching code for you would be icing on the cake.
That sounds like one of the best ideas I have heard in a long time . . . at least the first part of the idea. Haven't thought enough about the second part to know if that is fraught with any problems . . .
This is a fantastic idea.
It should be possible to do this. I doubt it will end up in Whidbey, but what do I know? Any VS 2005 people out there care to comment on this?
It is an important intellisense pattern. I mean, how often do you find yourself simply catching System.Exception and moving on? Certainly, this is terrible programming practice, but many people use it. We need to make it easier for you to do the right thing. Consider VB.NET, where the default code-complete pattern for try-catch is
Catch E As System.Exception
This is bad. What you are suggesting is good. Let's see what we can do.
One of the ways that languages typically implement functionality like this is through checked exceptions. The Java language, for instance, has the "throws" keyword. Christopher Brumme posted an excellent informative article on the CLR's exception model which everyone should read. Actually, IMHO everyone who works with the CLR on a regular basis should read every article Chris writes, whether you understand them or not. Anyway, he addresses the issue of checked exceptions in his article, but from a typically, for him at least, theoretical point of view. In it, he writes:
"The above text has described a pretty complete managed exception model. But there’s one feature that’s conspicuously absent. There’s no way for an API to document the legal set of exceptions that can escape from it. Some languages, like C++, support this feature. Other languages, like Java, mandate it. Of course, you could attach Custom Attributes to your methods to indicate the anticipated exceptions, but the CLR would not enforce this. It would be an opt-in discipline that would be of dubious value without global buy-in and guaranteed enforcement."The gist of his argument is that in a multilanguage system like the CLR, a feature like this is either required, or not very useful. If it is required, he contends that it hampers the ability for any given language to be productive and simple.
I tend to disagree that it is necessary for a feature like this to be as pure as he needs it to be. I'd love to see something like this implemented, via custom attributes or some other mechanism, as simple a metadata based "hint" as to which exceptions might escape, rather than a hard rule which comes with the full gammut of compiler errors and the like as in Java. I think it would be more than marginally helpful especially for productivity. But I'm not nearly as smart as Chris, so I'm sure I'm overlooking something. It also seems to me like it's possible for the compiler to detect the set of exceptions that may escape a particular method and put the metadata in for the developer, but the complexity of that solution is far beyond my current knowledge of both the CLR and its compilers.
Chris' blog began at gotdotnet:
but is now hosted on msdn: