PE>>> the C routines, just like you see in the ISO C standard.  My error

 PE>>> handling routines have this in the comment block of the error.h.



 PM>> Actually, the comments in error.h are not entirely correct (wildly

 PM>> inaccurate is closer to the mark :-)). For example:



 PE> You've missed the entire point.  They are DESIGNED to be able to be used

 PE> in a client-server environment.  Also to enable easy language

 PE> translation. They have actually been IMPLEMENTED to meet the absolute

 PE> minimum requirement of most utilities, which is English only, printf's

 PE> everywhere.  So no-one has any excuse not to use my routines,
"because I

 PE> don't want to drag in an entire error-handling system, just for my

 PE> 50-line utility program".  You DON'T drag in heaps, with the minimum

 PE> environment.  I another environment, you may be loading the strings from

 PE> a resource file - all totally hidden from the user of those

 PE> error-handling routines.



Come on Paul, this is a total cop out. Someone wanting to use your error
handling is going to read the documentation. The fact is, the documentation
is completely misleading about the capabilities of the system. The
documentation must be accurate or it's worse than useless. If you haven't
added features yet, then say so. If you don't need to check the result of a
function now but will in a future version, then *document* this fact.



What you're basically saying is that you've desgined (and documented) your
error handling one way and implemented it a different way. If someone wants
to use it as designed they'll have to write it themselves. Is this the
great benefit that I receive from using PD code? Sounds easier to just
write my own from scratch.



 >>> /*  void errorInit(void);                                    
       */

 >>> /*                                                           
       */

 >>> /*  This function should be called straight after
errorDefaults().   */

 >>> /*  Although it is possible for this function to fail,
errorTerm()   */

 >>> /*  should always be called to enable the error condition to
be      */

 >>> /*  reported.                                                
       */



 PM>> Since errorInit is defined as



 PM>> #define errorInit() errorReset()

 PM>> #define errorReset() (error.errorOccurred = 0)



 PM>> I can't see how it can fail.



 PE> Because when it is changed to



 PE> void errorInit()

 PE> {

 PE>     error.languageFile = fopen("binkley.lng", "r");

 PE>     error.message = malloc(atoi(fgets(buf, sizeof buf,

 PE> error.languageFile)));    blah blah blah; }



 PE> there will be plenty of scope for errors.  In which case errorTerm() will

 PE> be implemented as



 PE> void errorTerm()

 PE> {

 PE>     if (error.initFailed)

 PE>     {

 PE>         printf("unable to open binkley.lng\n");

 PE>     }

 PE> }



 PE> or similar.



But the facility doesn't exist *now*. The doco implies that it does.



 PM>> There is no facitlity to stack errors in this routine. Any error message

 PM>> that has been set will be delivered (via printf()).



 PE> Except when re-implemented for client server.



Again, the doco is wrong for the current implementation.



 >>> #define ERROR_INTERNAL "ERR001 Internal error file %s
line %d\n"

 >>> #define ERROR_OPEN_INPUT "ERR002 Failed to open file %s
for input\n"

 >>> #define ERROR_UNEXPECTED_EOF "ERR003 Unexpected
end-of-file on %s\n"

 >>> #define ERROR_MEMORY "ERR004 Insufficient memory
allocating %ld bytes\n"

 >>> #define ERROR_OPEN_OUTPUT "ERR005 Failed to open file %s
for output\n"



 >>> #define INTERNAL_ERROR() (errorSet(ERROR_INTERNAL, __FILE__,
__LINE__))



 PM>> These defines are not used by any of the code. Why are they there?



 PE> I tentatively decided that there will be "standard"
errors, rather than

 PE> every single application having to define it's own



 PE> "TBK001 Insufficient memory allocating %ld bytes\n"



 PE> There would instead be an



 PE> "ERR004 Insufficient memory allocating %ld bytes\n"



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

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



I think you'll find that in general IBM only issues a particular message
from one routine. You wont get 10 different routines issuing
"IEC201E... ". You may get 10 routines calling the routine which
issues this message though.



One of the error handling systems that our area implemented for our own use
was similar to what you are suggesting. We basically have a file of message
numbers which are attached to an error message that has place holders for
variables, similar to printf. To use it you pass the error number and the
variables to substitute in. It works very well, except it's a bit of a pain
to use, so the usage of it has dropped off.



 PE>>> Paul Markham is already using dtsplit(), which is another
sub-part of

 PE>>> it. I'm not sure how he knew he could use that though, as I don't

 PE>>> recall there being a decent interface spec to it.  Although there

 PE>>> could be, there's more comments than code in it.



 PM>> Nah, it's just that I'm brilliant :-)



 PE> There must be a decent interface spec!  :-)  BFN.



Actually, it does have very good specs. They documented *exactly* how the
routine is used (take note Paul!). I didn't even need (or bother) to look
at the code to see how it was implmented.



Paul



--- GoldED/2 2.42.G1114