Re: warnings

On Wed, Jan 24, 2001 at 02:15:56PM -0600, Ben Collins-Sussman wrote:
>
> So suppose libsvn_wc is working, deep down in a bunch of call frames,
> and it's trying to do 5 things. However, it wants to emit a warning
> about the 2nd action, and then move on to the 3rd, 4th, and 5th
> actions.
>
> Right now, we have no way to do this. If I throw a "non-fatal"
> svn_error_t, the top-most recipient can choose not to quit. But big
> deal; I've lost my call stack!
>
> It would be great to register some kind of "warning" function with
> libraries; this function would need to be available at all call-stack
> levels, of course. Perhaps one way to do it is to sneak it into the
> global error pool somehow?
>
> Thoughts?

mod_dav returns non-error cases in a linked list. As it does the (recursive)
processing, it can simply prepend/append the errors to the list.

Warning functions are a royal pain in the ass. You need to propagate context
there, and invariably *two* people will want to set a warning function
(*especially* if you follow your "sneak it into the global error pool"
approach). Or when you call the warning function, you won't pass enough
information for it to do the right job. etc.

IMO, build a linked list of issues/warnings, and return them. Note that you
might even be able to use svn_error_t in there. Something like:

  typedef struct svn_warning_t {
      int warn_code;
      const char *warn_msg;
      svn_error_t *err; /* may be NULL */
      struct svn_warning_t *next;
  } svn_warning_t;

Thus, you can associate an underlying *error* with a given warning. For
example, you might have a case where APR returns a permission error trying
to iterate over a directory. Fine, the recursive crawl creates a warning
record saying "can't crawl FOO", associate the APR error with it, link it
into the link, and continue the crawl.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/