TIP: Click on subject to list as thread! ANSI
echo: public_domain
to: Paul Edwards
from: Paul Markham
date: 1994-01-12 23:26:06
subject: pdgoal.txt 1/

[much of Paul's usual ranting deleted...]



 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.



Actually, the comments in error.h are not entirely correct (wildly
inaccurate is closer to the mark :-)). For example:



>/*  This subsystem if used as designed will enable your applications */

>/*  to work in a client-server environment, and also allow           */



Not true, since errorTerm calls printf(). This is unlikely to be what you
want under client-server. In fact, it will also cause problems in
environments where you can't use printf() such as Windows and Presentation
Manager.



What you need is a function that gets the error message from the buffer.
You can then send it back to the client or display it in a window.
Something like:



#define errorFetch(s) {strcpy((s), error.buf}



>/*  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.                                                        */



Since errorInit is defined as



#define errorInit() errorReset()

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



I can't see how it can fail.



>/*  void errorSet(char *fmt, ...);                                   */

>/*                                                                   */

>/*  This function is used to set an error.  fmt should point to a    */

>/*  unique format string, with specifiers similar to printf() to     */

>/*  identify the parameters to follow.  It is the users              */

>/*  responsibility to make sure that as well as the format           */

>/*  specifiers, there is other information in the format string      */

>/*  that makes the errors unique.  If this function fails, another   */

>/*  error will be set, which cannot be cleared by errorClear() or    */

>/*  errorFlush().  If an attempt is made to call errorSet(), when    */

>/*  an error has already been set, the subsequent call will be       */

>/*  ignored.                                                         */



Again, this function can't fail. The last two sentences are total garbage.



>/*  void errorFlush(void);                                           */

>/*                                                                   */

>/*  This function is used for "stacking" errors, when
multiple       */

>/*  errors are desired.  The error flag is cleared, but when         */

>/*  errorTerm() is called, all "stacked" errors will be
delivered.   */



There is no facitlity to stack errors in this routine. Any error message
that has been set will be delivered (via printf()).



>#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__))



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



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

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

 PE> there being a decent interface spec to it.  Although there could be,

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



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



Paul



--- GoldED/2 2.42.G1114

* Origin: It's life Jim, but not as we know it (3:711/934.1)
SEEN-BY: 635/514 711/809 934
@PATH: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.