On 10/19/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> Mark Phippard wrote:
> > On 10/19/07, David Glasser <glasser@davidglasser.net> wrote:
> >>> Maybe that is all you have been proposing, in which
> >>> case I'd be OK. I just want to use the API from JavaHL and not get an
> >>> error or perform extra server roundtrips. By the way, distinguishing
> >>> the reason for the error in JavaHL is not always as easy as it sounds.
> >> I don't see why getting an error is a problem. Look, here is what you do:
> >>
> >> static someReturnType mphippardSvnLog(args) {
> >> try {
> >> return svnLog(args, true);
> >> } catch (MergeinfoNotSupportedException e) {
> >> return svnLog(args, false);
> >> }
> >> }
> >>
> >> What's so hard about that?
> >
> > Aside from the fact that we do not throw nice exceptions like that,
> > nothing. I am talking about the UI not the code. As for the code, I
> > will probably have to do something stupid and error prone like match a
> > string in an exception message.
>
> Really? The ClientException class contains the specific apr error
> number for the generated error. Couldn't you just compare it with the
> mergeinfo_not_supported error code (which won't change), instead of
> matching the string in the error message?
Dan has been using SubversionException a lot more recently. Not sure
why, but it does not have the APR error code. The other issue is that
no one has gone to the trouble to create an SVNErrorConstants.java
where we define all these error codes. The methods you call do not
document them in the JavaDoc etc.
I am not saying we have not dealt with this before or cannot here.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 22:44:11 2007