Re: error_t (was Re: [Gnu-arch-users] Nit)

[Robin Farine]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    Tom>     [error_t observations]

    Tom> Thanks:  huge help on several points.

At least we seem to have been able to converge to something. Happy to
hear it helped, I am still in the fog though. But if you come up with
an implement ion, I'll be one of the firsts to borrow it; error
handling has often been a source of dissatisfaction. I would like to
consider this problem properly solved and not to have to think about
it again.

    Tom>   Perhaps a generic way of "wrapping" exceptions.  As in: "my module
    Tom>   got `cannot open'; i turned that into `configuration not found
    Tom>   [cannot open [too many descriptors]]' and pass the composite error
    Tom>   upwards."

I am not sure I follow you here. The advantage of logging an error
message where the error is detected and assigning a correlation value
to the error status returned is that this does not require any memory
allocation to bind related errors together as the stack unwinds. But
maybe you already have something in mind?

All this makes me think that what I called error_t in [error_t
observations] should rather have been called error_type_t. Error
instances most probably need to be mutable to make any kind of error
correlation possible:

        struct error_t
        {
          error_type_t type;
          unsigned correlation;
        };

Then, 'err == talking_to_my_toothbrush' becomes 'error_type(err) ==
talking_to_my_toothbrush'.

    Tom> And that's _almost_ the flipside of the other two flipsides.  If you
    Tom> believe that bar's (now corrupt) state is sufficiently sandboxed, then
    Tom> it can just arrange to perpetually return fatal errors for every call
    Tom> (as you suggest).  But I have been (_maybe_ reasonably) lumping
    Tom> together "bar's state is corrupt" with "bar has hosed the entire
    Tom> process, proceed with extreme caution for a short distance and then
    Tom> stop."

OK, I think we agree on the general idea. But it will always be the
implementor of each concrete who will have the final word, whether it
is best to use preconditions/invariants/posconditions (which certainly
must abort when not verified) or an if (...) { set_error(...); return;
} like construct.

-- 
rnf