On 3 June 2015 at 20:29, Branko Čibej <br...@wandisco.com> wrote: > On 03.06.2015 17:10, Ivan Zhakov wrote: >> On 3 June 2015 at 17:19, Branko Čibej <br...@wandisco.com> wrote: >>> On 03.06.2015 15:31, Ivan Zhakov wrote: > >>>> I'm also not sure that we have to return error if we already reported it >>>> via notify_func in >>>> svn_repos_verify_fs3(). >>> >>> Out notification mechanism cannot replace API consistency. When an API call >>> fails, it must return an svn_error_t; surely you're not proposing that we >>> make an exception for svn_repos_verify_fs3? >>> >> This is depends whether check of corrupted repository is error or not. >> I mean that semantic could be: "please give me all/first corruptions >> in this repository via notify_func". > > Hm, well, that would be a different API than what svn_repos_verify_fs3 > documents. > Of course docstring should be updated in this case. My point was that we could define svn_repos_verify_fs3() API to report repository corruptions only via notify_func because these errors are special.
> An API user who wants an early exit can always trigger the cancel_func > in her notification handler and get SVN_ERR_CANCELLED in response. > The problem that it's could be hard to distinguish summary errors from repository corruption errors itself for API user. -- Ivan Zhakov
