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

Re: svn_stream_copy3() in svn_io.h

From: Edmund Wong <ed_at_kdtc.net>
Date: Wed, 08 Apr 2009 11:19:02 +0800

Greg Stein wrote:
> The error does need to be propagated back, yes. But those streams need
> to be closed.
>
> I believe you're going to end up with code something like:
>
> err = cancel_func(baton);
> if (err)
> {
> err = svn_error_compose_create(err, svn_stream_close(src));
> err = svn_error_compose_create(err, svn_stream_close(dst));
> return err;
> }
>
> (note: the above isn't syntax perfect; just illustrative)
>
> I don't recall how many SVN_ERR() uses are in that function. If a lot,
> then you might end up with logic something like:
>
> err = do_something(...)
> if (err)
> goto err_cleanup;
> ...
> err_cleanup:
> err = svn_error_compse_create(err, ...

I've been reading a bit of code and came across these goto usage.
No offense, but, I don't think I have seen that many gotos
in a long time. Rather than talk about the ingrained teachings
of not using goto's in any program; I think it's better for me
to understand the rationale. Again, I meant no offense to
anyone here. I'm just quite surprised by the usage of goto
and really need some sort of clarification. (I think the
last goto I saw was in a BASIC program I did a long time
ago.)

> Propagating the error is correct. You nailed that one. But it is
> possible that somebody will decide to ignore/discard the error as
> "allowable". The program won't necessarily exit. Thus, the advertised
> "will close" still needs to be met.

While my code wasn't as succinct nor concise, it had a similar
feel; but I don't know if I captured the essense right. I think
I'll need some sort of peer-review of my lousy C coding.

Thanks

Edmund

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1588846
Received on 2009-04-08 05:19:35 CEST

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.