Re: svn commit: r14098 - in trunk: . subversion/libsvn_client subversion/tests/clients/cmdline

John Szakmeister <john@szakmeister.net> writes:
> I guess it depends on your point of view. In this case, if I document
> that you can only send it svn_opt_revision_base/committed/working and you
> send it something else, then you violated the API. In that case, I feel
> assert() is okay (in much the same way that we verify that input buffers
> and paths aren't NULL). This function leaves the job of input validation
> to the next level up. *shrug* I don't care all that much, I'm just
> trying to understand why a runtime error is better than assert() in this
> case. :-)

Ah. I see what you're saying. Here are my thoughts.

First, an error is much easier to understand.

Second, we can force every caller to validate the revision, or it can
just pass the revision along and count on this function to error if
appropriate. Result: avoidance of duplicated code.

That's why I would prefer an error.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 5 22:42:13 2005