Home » Archived » DSDP - Real-Time Software Components (RTSC) » Re-throwing an error
| Re-throwing an error [message #3895] |
Tue, 09 June 2009 16:04  |
 Ramsey Harris
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
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
|
|
|
| Re: Re-throwing an error [message #3902 is a reply to message #3895] |
Wed, 10 June 2009 15:47  |
Eclipse User |
|
|
|
Originally posted by: bob.biosbob.biz
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
|
|
|
| Re: Re-throwing an error [message #3908 is a reply to message #3902] |
Wed, 10 June 2009 18:01 |
Ramsey Harris
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Interesting idea, creating a local error block. Thanks for that.
But my original question was really just asking if its okay to call Error_raise() on a signaled error block *without* first calling Error_init(). I would rather not have to call Error_init() if I don't need to.
Thanks
~ Ramsey
Bob Frankel wrote:
> 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
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 03:16:48 GMT 2024
Powered by FUDForum. Page generated in 0.03325 seconds |
] 
Search
Help
Register
Login
Home
