Re: warnings

On Thu, Jan 25, 2001 at 10:30:56AM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
> > 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.
>
> The structure is a nice idea -- but I still don't understand what the
> catching/throwing mechanism should be.

I was thinking explicit, rather than standardized like svn_error_t. IOW, you
have a function argument: svn_warning_t **warnings.

> Right now nearly every svn_* routine returns an svn_error_t, and all
> callers check for this; if any routine returns anything but zero
> (SVN_NO_ERROR), the each function in the call stack just aborts what
> it's doing and throws the error upwards.
>
> How on earth do we build warnings into this existing system?

You simply don't. It was designed for errors. Warnings have to use a
different mechanism, and they (obviously) wouldn't be pervasive without a
ton of change. But I think that's okay... warnings aren't common.

In fact, the warning struct above is mostly a way to say "I got this error,
but was able to continue anyways." IOW, there are no "warnings" but just
ignored errors.

I found in mod_dav that this worked quite well. Not sure whether it will
apply well to a cmdline client.

Let's flip this around: what warnings are you designing for? What are the
requirements for warnings here? [before starting a design]

Cheers,
-g

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