The essence of throw docs

[Georg Wrede]

Walter Bright wrote:
> Graham St Jack wrote:
> 
>> It is also very helpful when writing code to know that a function you 
>> are calling won't throw an exception - it means you have three kinds 
>> of functions: those that don't throw, those with comments telling you 
>> what they throw, and those that you need to fix the comments for.
> 
> 
> Experience with this indicates that it is impractical to specify what 
> exceptions a function may throw. The only practical states to specify are:
> 
> 1) does not throw
> 2) always throws
> 3) might throw
> 
> What is thrown is not reliably computable. For example:
> 
> import foo;
> void test()
> {
>     foo.bar();
> }
> 
> What exceptions does test() throw? That would require knowledge of the 
> import foo, which is not necessarily knowable and can change over time.

So both of you are right!

(Heh, couldn't resist ;-) )



What my comment above incidentally uncovers is that this is a profound 
aspect that especially Programmer Group Managers should be aware of.

The ability to see things /simultaneously/ from the perspective of the 
library programmer, the app programmer, and Real Reality, is fundamental 
to the success of the Group. If all three of these persons can see it 
from all three points of view, the better. And much better. (It's a pity 
that all we have left in Finland currently on the job market are 
ex-truck-drivers. Everybody else already are in managerial positions at 
Nokia, F-Secure, and a few other firms.)