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.
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? If now
we say, "ok, we want all svn_* routines to be able to return *both*
warnings and errors?", what does our exception handling then look
like? Do all callers then need to check for both warnings and errors
separately? (In other words, the usual "if (err) return err;" won't
be enough anymore.)
Let's devise something good here.
Received on Sat Oct 21 14:36:19 2006