Re: GException notes

[Havoc Pennington <hp redhat com>]

Havoc Pennington <hp@redhat.com> writes: 
> At that point the advantages of an error argument vs the
> strtoul()-style global object are:
>  - fewer side effects (because you can create local "error contexts"
>    in callbacks and such)
>  - cleaner threads situation (you can even pass errors between
>    threads)
>  - the requirement to explicitly handle or not handle errors so people
>    have to think about errors when typing in the function call and
>    can't forget to deal with them.
> 

Karl suggested an in-between solution on IRC which addresses issue #1, 
which is a stack of global error objects that have to be
pushed/popped.

So this would look like:

void frobate()
{
  g_error_frame_push();
  foo();
  if (g_error_is_set()) /* if error set in current frame */
    /* foo() failed fatally */;
  g_error_frame_pop(); /* pop the frame used by foo(), so we didn't 
                          have side effects */
  
  if (!blahblah())
    g_error_set("Frobate failed"); /* set an error in the frame our
                                      caller pushed */
 
}

Error pileups with foo() are avoided by the frame push/pop 
surrounding it. So this addresses the first and I think most important
issue with global errors.

So the three variants of the basic scheme are:

#1 (strtoul() style):
  clear_global_error();
  frobate();
  if (check_whether_global_error_set())
    handle_error();

 with optional error-ignore mode:
  frobate();

#2 (GConf style):
  GError* err = NULL;
  frobate(&err);
  if (err != NULL) 
    handle_error();

 with optional error-ignore mode:

  frobate(NULL);

#3 (Karl's idea):
  push_error_frame_on_global_stack();
  frobate();
  if (check_whether_current_frame_has_error_set())
     handle_error();
  pop_error_frame();

 no error-ignore mode I don't think, you would corrupt the 
 current frame.

And the return value scheme is UNIX API style:

#4:
 if (!frobate())
   handle_global_error_object();

 error-ignore mode is:
  frobate();

All 4 of these meet the three design criteria. 

Pros and cons:
#1: 
  3 disadvantages quoted at the top of this mail - 
    threads are gross, side effects due to lack of local 
    contexts, and easy to forget to handle errors

  has an error-ignore mode
  avoids function argument
  avoids return code

#2: 
  avoids the three disadvantages of globals
  has error-ignore mode
  has an extra function argument  
  avoids return code

#3:
  avoids the function argument
  avoids return code
  has two of the three disadvantages of globals

#4:
  has a return code
  has the three disadvantages of globals, though the 
    impact of weird side effects is lessened since 
    side effects can't cause fatal failure to be reported
    incorrectly

Havoc