PM>> If you're going to put error handling code in your program (probably a

 PM>> good idea :-)), then I think you should use a standard approach. Don't

 PM>> mix 'CC' and 'try' as this is going to confuse people. Being consistent

 PM>> is usually a good idea. Except if you are consistently inconsistent :-)



 PE> Well I guess this boils down to the same as bracket-matching style,

 PE> debate gets very heated.  You seemed rather attached to try(), so I've

 PE> added it to the standard, although I can take it out again if you think

 PE> so, since it's still in draft form.



Which style of error handling could very easily become a religious debate.
However, I don't think anyone would argue that you should take a consistant
approach to it.



Since I haven't given TRY() a go yet, I've got no idea whehter it works well or not.



 PM>>>> do

 PM>>>> {

 PM>>>> try(func());

 PM>>>> if (something)

 PM>>>> {

 PM>>>> do

 PM>>>> {

 PM>>>> try(func2());

 PM>>>> try(func3());

 PM>>>> }

 PM>>>> while(0)

 PM>>>> }

 PM>>>> try(func4());

 PM>>>> }

 PM>>>> while(0);



 PM>>>> if an error is detected in func2() or func3() then you are still

 PM>>>> going to execute func4().



 PE>>> Which is what you want normally.  func() might have opened
a file, and

 PE>>> func4() needs to close it.  You want the file closed - error or not!

 PE>>> Anyone who has any complaints should do an if (ALLOK)
try(func4()) if

 PE>>> that's what they're into.



 PM>> The whole idea of this is to avoid having 'if (ALLOK)' throughout your

 PM>> code.



 PE> I'm saying that in normal programming, you wouldn't have an if (ALLOK)

 PE> around func4().  Because in fact, if that's what you wanted, you would

 PE> have put it straight after func3()!  Nope, no use for a goto here.  BFN.



When I originally wrote this, I was thinking that under most circumstances
you wouldn't want func4() to execute. I guess it really depends on what
you're trying to achieve.





Paul



--- GoldED/2 2.42.G1114