from what i can tell, calling Error_init (again!) will effectively reset
the error block.... [i seem to recall an Error_clear function from the
past, though its implementation was probably just a called to Error_init
and was therefore dropped]
as an alternative, however, the function below (which is passed 'eb')
could declare its *own* Error_Block on the stack; the latter Error_Block
would be passed to Memory_alloc and -- depending upon the outcome -- the
original 'eb' would be passed to Error_raise....
this approach would be *necessary* if this particular routine want to do
some cleanup *before* calling Error_raise on the original 'eb'.... why?
because 'eb' could be NULL and passing it to Memory_alloc could lead to
premature program termination....
this design also enforces the "one error per one error block" approach...
but still, you can reuse error blocks by simply calling Error_init (again!)
Ramsey Harris wrote:
Champs,
Is it safe to call Error_raise() on a signaled error block? Or might
some state information from the previous error "leak" into the second
error and invalidate its state?
For example, I have some code which requests memory. If the heap runs
out of memory, it will raise an error. But this is a low level and
very common operation. I would like to add a second error event to the
error log which indicates who was requesting the memory.
packet = (RcmClient_Packet*)Memory_alloc(NULL, size, sizeof(Ptr), eb);
if (Error_check(eb)) {
Error_raise(eb, RcmClient_E_packetAllocFailed, size, 0);
goto leave;
}
Is this safe to do, or must I call Error_init() before raising the
second error?
Thanks
~ Ramsey