You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alexey Mahotkin <al...@hsys.msk.ru> on 2001/02/02 22:47:10 UTC

Re: warnings

>>>>> "BC" == Ben Collins-Sussman <su...@newton.collab.net> writes:

BC> How on earth do we build warnings into this existing system?  If now we
BC> say, "ok, we want all svn_* routines to be able to return *both*
BC> warnings and errors?", what does our exception handling then look like?
BC> Do all callers then need to check for both warnings and errors
BC> separately?

IMHO stack of warnings should be made singleton object (as in design
pattern).

You could implement it in C using static stack somewhere in warning.c, and
accessor functions, available in warning.h:

init_warnings();

add_warning(msg);

list = get_warnings();


This does not require of you to change interface of any function, and will
be implemented in no more than 100 lines, including extensive copyright
info :)

--alexm

Re: warnings

Posted by Greg Stein <gs...@lyra.org>.
On Sat, Feb 03, 2001 at 06:46:34PM +0300, Alexey Mahotkin wrote:
> >>>>> "GS" == Greg Stein <gs...@lyra.org> writes:
> 
> GS> That interface implies global variables... IMO that is a non-starter.
> 
> Those global variables are static (I mean C keyword here) and completely
> hidden by accessor functions.

I'm thinking thread-safety. Not visibility.

All of the SVN libraries are intended to be completely thread-safe.

> GS> I believe warnings are a special case. Most functions will return
> GS> errors rather than warnings. For those that *do* return warnings, they
> GS> can return a special structure for it.
> 
> Singletons are well-defined and well-understood concept and imho they suit
> perfectly here. 

I know what singletons are :-), but can agree to disagree on their relevance
to this problem.

Cheers,
-g

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

Re: warnings

Posted by Alexey Mahotkin <al...@hsys.msk.ru>.
>>>>> "GS" == Greg Stein <gs...@lyra.org> writes:

GS> That interface implies global variables... IMO that is a non-starter.

Those global variables are static (I mean C keyword here) and completely
hidden by accessor functions. 

GS> I believe warnings are a special case. Most functions will return
GS> errors rather than warnings. For those that *do* return warnings, they
GS> can return a special structure for it.

Singletons are well-defined and well-understood concept and imho they suit
perfectly here. 

--alexm

Re: warnings

Posted by Greg Stein <gs...@lyra.org>.
That interface implies global variables... IMO that is a non-starter.

I believe warnings are a special case. Most functions will return errors
rather than warnings. For those that *do* return warnings, they can return a
special structure for it.

Cheers,
-g

On Sat, Feb 03, 2001 at 01:47:10AM +0300, Alexey Mahotkin wrote:
> >>>>> "BC" == Ben Collins-Sussman <su...@newton.collab.net> writes:
> 
> BC> How on earth do we build warnings into this existing system?  If now we
> BC> say, "ok, we want all svn_* routines to be able to return *both*
> BC> warnings and errors?", what does our exception handling then look like?
> BC> Do all callers then need to check for both warnings and errors
> BC> separately?
> 
> IMHO stack of warnings should be made singleton object (as in design
> pattern).
> 
> You could implement it in C using static stack somewhere in warning.c, and
> accessor functions, available in warning.h:
> 
> init_warnings();
> 
> add_warning(msg);
> 
> list = get_warnings();
> 
> 
> This does not require of you to change interface of any function, and will
> be implemented in no more than 100 lines, including extensive copyright
> info :)
> 
> --alexm

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