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