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

Re: svn commit: r37709 - trunk/subversion/libsvn_subr

From: Branko Cibej <brane_at_xbc.nu>
Date: Wed, 13 May 2009 12:50:49 +0200

Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-05-12 21:11 Greg Stein <gstein_at_gmail.com> napisaƂ(a):
>
>> On Tue, May 12, 2009 at 20:20, Branko Cibej <brane_at_xbc.nu> wrote:
>>
>>> Arfrever Frehtes Taifersar Arahesis wrote:
>>>
>>>>> Why is this necessary?
>>>>>
>>>>> If the error is useful, the full error message can be returned (as wrapped
>>>>> error?) in the svn_error_t* returned by this function
>>>>>
>>>>>
>>>> The doc string of svn_dso_load() contains:
>>>> "If @a libname cannot be loaded set @a dso to NULL and return @c SVN_NO_ERROR."
>>>>
>>>> The error message might be useful to find bugs such as the one introduced
>>>> in r35309+r35385+r36823.
>>>>
>>>>
>>> Never mind if it might be useful; we do not print anything from our
>>> libraries. It's just Not Done and I don't care about broken libraries
>>> that do expect to be able to print anything.
>>>
>> To be fair, the print is within SVN_DEBUG which means "only svn devs"
>>
>> But yah: rev the API and improve the error return. Consumers can
>> always throw out the error.
>>
>
> `svn`, `svnsync` etc. should probably print the error message
> retrieved from apr_dso_error(), but they must try to continue to work
> when dynamic loading of a library failed. For example, when dynamic
> loading of libsvn_ra_neon-1.so.0 fails during accessing a repository
> through http:// protocol, libsvn_ra_serf-1.so.0 might be available, so
> libsvn_ra-1.so.0 should try to dynamically load libsvn_ra_serf-1.so.0.
>
> svn_dso_load() is called only by Subversion libraries (libsvn_subr,
> libsvn_fs, libsvn_subr), not by `svn` and other programs, so I'm not
> sure how to implement sending of error message from a library function
> (which calls svn_dso_load()) to a program without returning error from
> this function.
>

Why do you want to make things complicated? You can safely assume that
*if* there's a chance that an alternate DSO can be used, the caller of
svn_dso_load should take care of that silently. I don't want to see "You
requested serf but we're using neon instead" printed every time I do
anything network related; the semantics should be the same, a user
doesn't give a damn which library is used as long as stuff works.

If, on the other hand, we really do decide that such info is an
important user-facing interface, then by golly you shouldn't just print
it, you should have your caller of svn_dso_load accept a notification
callback parameter -- same as we do for all other progress and status
reporting. But that's a decision to be made on a case-by-case basis and
does not belong in svn_dso_load.

-- Brane

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2234920
Received on 2009-05-13 12:51:13 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.