There is one part of the idea that I'd like to salvage, though, and that's having some clear documentation right there in the code about what kinds of exceptions I can expect to see a procedure throw.
At the very least it'd be useful for when I'm wearing my "DLL author" hat, since it'd give me an easy way to look through the public interface and make sure exceptions won't be causing unrighteous leakage of implementation details for the end-user. I'd rather not put users in a situation where they have to look at the framework source in order to interpret an exception. It's kind of irritating when that happens.
I think it's really not something that should require special language statements, though. A static analyzer should be able to automatically figure it out.
At the very least it'd be useful for when I'm wearing my "DLL author" hat, since it'd give me an easy way to look through the public interface and make sure exceptions won't be causing unrighteous leakage of implementation details for the end-user. I'd rather not put users in a situation where they have to look at the framework source in order to interpret an exception. It's kind of irritating when that happens.
I think it's really not something that should require special language statements, though. A static analyzer should be able to automatically figure it out.