[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-08-15 23:19:48 CEST

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
Received on Thu Aug 15 23:21:05 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.