Paul,



I read (probably in DDJ or CL) about a technique for handling similar to
the one you are talking about. The difference being that the errors were
"stacked" so that you could keep track of multiple errors. The
information would be contained in an array that looks like this:



struct

    {

    int function;   /* identifies the failing routine               */

    int error;      /* the error that occured                       */

    int info;       /* some extra info, eg number of being malloced */

    } error[100]



the size an types of the fields would need to be changed to whatever is
relevant in you allication.



To use it you would have code like this:



main()

    { initialise();

    if error

        prt_error;

    .

    .

    }



initialise()

    {

    allocate_buffer();

    if error

        set_error(INITIALISE_RTN, INITIALISE_FAILED); .

    .

    }



allocate_buffer()

    {

    Malloc()

    if error

        set_error(ALLOCATE_BUFFER_RTN, ALLOCATE_BUFFER_FAILED); .

    .

    }



Malloc()

    {

    malloc(buffsize);

    if error

        set_error(MALLOC_RTN, MALLOC_FAILED, bufsize);

    .

    .

    }



You could then print the whole calling sequence. It also allows you to
intercept an error at any level and try another techinque. If, say, the
allocate_buffer failed, you could then decide to use virtual buffers that
are swapped out to disk.



Of course, you'd use something more meaningful for the error than "xyz
routine failed".



The real problem then is, what happens if the error table isn't big enough?
You could try and recover, by allocating more memory, but this may also
fail, so you'd have to eventually treat this as a fatal error and terminate
the application.



Some of our assembler systems at work use a similar approach. When they
detect an error, they format a message (including the routine name) into a
message buffer, and then set a return code of 4 for the calling program.
The calling program can then format its own message and/or print the ones
already in the buffer and/or abend the job. Normally, the message buffer
doesn't fill up, however, sometimes a program gets into a loop and keeps
adding messages. If the message buffer does fill up, then the whole thing
is dumped to the job log and cleared.





Paul



--- GoldED 2.40