Re: svn commit: rev 2977 - trunk/subversion/include

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> Philip Martin <philip@codematters.co.uk> writes:
> > Do we need to support applications that want to use APR_OS_START_USEERR
> > without conflicting with Subversion? We could reserve some spare
> > categories after 17 and provide a name for the first application error
> > number.
>
> How would such a conflict happen?
>
> There's no problem if two libraries want to use the same numbers in
> their error codes. Callers know which library's functions they're
> calling, so they will be checking error codes "in the right context",
> so to speak.

I suppose interpretation "in the right context" is the only solution
that will work if libraries other than subversion are being used.
However if the application uses only Subversion, it may want to use
apr_status_t to report it's own errors within the application code.

   apr_status_t app_function()
   {
        if (...)
           /* Yikes! An application error */
           return APP_LOGIC_ERROR1;

       svn_error_t* err = svn_client_xxx();
       if (err)
          return err->apr_err;
   }

   int main()
   {
       apr_status_t app_err = app_function();
       if (app_err)
          /* Handle error */
   }

Now how does the application define APP_LOGIC_ERROR1? At present the
only way to avoid clashes is to translate all Subversion errors into
application errors and never propogate the subversion ones.

Our client, svn, gets its own category. I'm suggesting something
similar for other applications.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org