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

[Tom Lord]

    > From: Robin Farine <address@hidden>

    [error_t observations]

Thanks:  huge help on several points.

Here's what I'm getting:


1) Abstract the error_t interface more.  [-t slaps forhead and
   goes... "uh.. right... yeah, I knew that, really...." :-).]

2) Don't worry about fancier pattern matching for errors until you are
   certain you need it.  With your nicely abstracted interface it's
   easy enough to add later.  [-t: </blush>.  Nice touch on wrapping
   the decls in a macro, in this regard: the backwards compatability
   is then that (unmodified) existing error types just become
   "singleton error classes" which are not part of any larger type.]

3)

    > In cases where a call at the application level involving deeply nested
    > calls fails, if the top level function only produces an error message,
    > say "configuration not found", the user can hardly know what really
    > caused it. However, if some of the nested calls also log an error
    > message, particularly the most nested one, these messages can be
    > grouped together using the timestamps and correlation value to provide
    > the user with a kind of user friendly call trace. He would see
    > something like "cannot open ~/.gnafu" or "too many descriptors"
    > preceding the "configuration not found" message.

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

  I already want a way of wrapping exceptions for the sake of
  converting errors to `unexpected_error' -- so maybe just build that
  in as a generic capability.  Yup, yup, yup.

    > Thus, this does not help the runtime to recover but it does help users
    > to fix a lot of problems by themselves without diving into the source
    > code or posting to the mailing-list. In some way, it helps *you*.

  Clearly.  Win, win, win.


4)

    >     Tom> If bar gets some error that indicates its private state has been
    >     Tom> corrupted -- it is forced to break promises to its callers -- 
then an
    >     Tom> orderly abort is the only option left.

    > Not necessarily. I would prefer it to let the callers do what they
    > need to do during call backtracking, which might be easier than having
    > a SIGABORT handler that takes care of everything. The application code
    > is then free to choose between an abort(), exit(), exec() or a even a
    > system reset.

I think the only difference in opinion we have (had?) is "abort from
deep in the stack" or "abort from some call-site".  You might be right
that "abort from the call-site" comes out cleaner but I'm reluctant:

The flipside of that difference is "callee trusts caller to really
abort (in some sense)?"   With deep-in-the-stack handling I can write:

        catch_fire ()
        {
          do_what_the_nth_level_caller_and__handlers_want ();

          /* what?  this isn't supposed to be reached: */
          panic ("fatal condition handlers returned!??!?");
          exit (2);
        }


    > I liked the idea that the caller decides that the callee is allowed to
    > call abort() by passing a null pointer as error handle. 

Yeah -- that came out of some earlier discussion in this thread.  The
hacklerab alloc_limits functions work that way already (roughly) but I
hadn't thought to generalize it because I hadn't thought to
sufficiently abstract the error_t interface!


    > Also, if bar()
    > is critical, it can ensure to not be called again once its state has
    > been corrupted using preconditions/invariant.

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


As I said: Thanks, huge help on several points.

-t