PM>> Actually, it does have very good specs. They documented *exactly* how

 PM>> the routine is used (take note Paul!). I didn't even need (or bother) to

 PM>> look at the code to see how it was implmented.



 PE> You should have taken the same attitude with the error handling stuff.

 PE> It works exactly like the documentation says it does.



My point is that the code *doesn't* work as documented.



[much deleted...]



You are missing my point. I'm not criticing the error handling routines.
What I'm criticising is the documentation which claims it does things it
can't. I agree with you on the need for this type of facility, but there is
no way your does everything it claims to do.



 PE>>> IBM stuff is similar, if you are running a general ledgers program,

 PE>>> you could easily get in the log, "IEC201E blah blah blah".



 PM>> I think you'll find that in general IBM only issues a particular message

 PM>> from one routine. You wont get 10 different routines issuing
"IEC201E...

 PM>> ". You may get 10 routines calling the routine which issues this

 PM>> message though.



 PE> This could be a better way of doing it.  Probably is actually.  I should

 PE> have a mMalloc() which sets the "ERR004", and anyone who
calls that gets

 PE> it. One thing I have started to believe is that the ISO C functions were

 PE> never meant to be called directly, but instead to be used as building

 PE> blocks.



I'm sure ANSI could have designed better routines except for the minor
problem of having to maintain compatability with all the old Unix code
around the place.



 PM>> One of the error handling systems that our area implemented for our own

 PM>> use was similar to what you are suggesting. We basically have a file of

 PM>> message numbers which are attached to an error message that has place

 PM>> holders for variables, similar to printf. To use it you pass the error

 PM>> number and the variables to substitute in. It works very well, except

 PM>> it's a bit of a pain to use, so the usage of it has dropped off.



 PE> What is the interface specs to it that make it a pain to use compared

 PE> with the alternative?  This is very interesting, because if my error

 PE> routines are as difficult to use, they will be basically useless.

 PE> However, I do not think they are difficult to use.  You can #define the

 PE> messages in your header files, with the text in there.  You don't have to

 PE> go to the hassle of sticking them in a file, or any other such rot.



It's biggest problem is that messages have to be defined in a central
location. They are defined by using assembler macros and the whole thing is
assembled into a load module and put in the link list. There was also
another table listing which routines could issue which messages. As far as
I can tell, this was done as a sort of forced documentation. If we ever
needed to change a message, then we could track down all the programs using
it.



The routines were geared towards assembler programs, and would have been
difficult to use in, say, COBOL. I did use them in some of the C program I
wrote though.



One thing we always did which is worth doing if you take this approach is
to include the routine name in any messages issued. This really helps when
you have some program deep in the guts of a system that is complaining.
Much easier to get a message saying



ABC1234E Getmain failed (SOMEPGM)



than just



ABC1234E Getmain failed.



 PE> Basically, in everything except the most trivial of programs which I

 PE> write, I will be using that error-handling routines.  They do exactly

 PE> what I want them to do, with no extra hardship for me.  And if used

 PE> universally, they make writing code SO much easier.  In the past, I used

 PE> to ignore most errors (return codes) because it was too much effort to

 PE> check them, and most of my code would be concerned with checking them,

 PE> reporting the error, and trying to abort. When have you ever put in a

 PE> check to see if fclose() was successful? Or if the NULL you got from

 PE> fgets() was because of a file read error (someone took the floppy out of

 PE> the drive), or because of end-of-file.  Well with XFILE using this error

 PE> handling strategy, it is a piece of piss to check this stuff. Basically,

 PE> you DON'T have to check if fclose failed, it happens automatically.



Last time I checked fclose() was in the packet sorted I'm currently writing
:-) This is also the first time I've ever done it :-)



The other approach, which is what C++ is doing, is to use exceptions. I
have seen some C implementations of exceptions but haven't tried any.



Paul



--- GoldED/2 2.42.G1114