PM>> Having the CC at the end of the line could make it easy to miss while

 PM>> reading the code. It would also be easy to forget to put it in. You

 PM>> could try something like:



 PE> Actually, I don't want to read it at all, but I'm using C as the

 PE> programming language, so that's the way it's got to be!



This can be your next project Paul. A language (based on ISO C of course)
that automatically does the error checking for you!



 PM>> #define try(x) x;if (!ALLOK) break;



 PM>> do

 PM>> {

 PM>> try(func1());

 PM>> try(func2());

 PM>> try(func3());

 PM>> }

 PM>> while(0);



 PE> You have to be careful with things like that if you want to have commas

 PE> in it, or else the macro will think that you are passing 2 parameters. I

 PE> guess we could use both the CC standard and the try standard.  What do

 PE> you think?  I used to leave out error checking because I didn't want to

 PE> pollute my code. I'm not looking to the try() acting so prominently.



Well, I figure that it works with assert(), so the compiler must be able to
figure it out.



If you're going to put error handling code in your program (probably a good
idea :-)), then I think you should use a standard approach. Don't mix 'CC'
and 'try' as this is going to confuse people. Being consistent is usually a
good idea. Except if you are consistently inconsistent :-)



 PM>> This method will have problems when you have code like:



 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 going

 PM>> 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.



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



 PM>> Of course, what you're really doing here is using the do...while as a

 PM>> goto. Using a goto the code could then be:



 PE> Shhhhh.  I've had people shot for less than that!



You'd have people shot for diagreeing with you. Or agreeing with you for
that matter. Or even not having an optinion on the subject :-)



 PM>> #define try(x, y) x;if (!ALLOK) goto y;



 PM>> try(func(), error);

 PM>> if (something)

 PM>> {

 PM>> try(func2(), error);

 PM>> try(func3(), error);

 PM>> }

 PM>> try(func4(), error);

 PM>> return;



 PM>> error:

 PM>> error handling code



 PE> There is no need to resort to this.  BFN.



This is basically what exceptions do. Of course, since the programmer never
actually codes a goto, then it's perfectly OK :-)





Paul



--- GoldED/2 2.42.G1114