Laurent,

> 
> > I also think that the example by Gary Howland a year ago, where a local
> > variable that contained a value was clobbered might not be as frequent
> > as the example encountered by Laurent in the Java WebServer, where the
> > local variable in question contained a return address.
> 
> You probably mean 'not as serious' - seems to me that local variables 
> are used more frequently, on the whole, than return addresses... But 
> I would feel seriously concerned about Java if I could not rely on a
> local variable keeping its value; whereas I can probably live with a
> principle of 'avoid throwing an exception from within a finally {}'.
> 

You're right.  I meant that the problem only occurs if you rely on a 
local variable *and* a synchronous exception is thrown.  
And less serious maybe in the sense that we jump off to Nirvana in
the RET case whereas we might read a wrong integer in the variable
case... but what if it's an object ref?  In any event, that discussion 
seems largely academic...

> 
> I don't see them as a possible speedup (as you mention, the cost, 
> performance wise, of a try..catch block is VM-dependent) as much
> as a compelling way of doing 'programming-by-contract'. You keep
> operations that correspond to contractual expectations within a try {}
> block and handle contract violations in the catch {}. So rather than
> using exceptions to 'detect' abnormal conditions, you use them to 
> _define_ what conditions you consider to be abnormal.
> 

 That's an interesting way of thinking about it.

> 
>  This seems to have become a common enough Java programming idiom 
> that the problem is IMHO a serious cause for concern.

I wholeheartedly agree.

	- Godmar