On Wed, 21 Mar 2007, Hyrum K. Wright wrote:
> Daniel Rall wrote:
> > Will singleStatus() ever throw ArrayIndexOutOfBoundsException? If so,
> > it might be more backwards compatible to wrap a try/catch block around
> > the Java one-liner to re-throw the exception as ClientException.
>
> I think the idea is valid, but I have a concern about the
> implementation. ClientException is basically just a wrapper around
> nativeException, with this constructor:
>
> /**
> * This constructor is only used by the native library.
> *
> * @param message A description of the problem.
> * @param source The error's source.
> * @param aprError Any associated APR error code for a wrapped
> * <code>svn_error_t</code>.
> */
> ClientException(String message, String source, int aprError)
> {
> super(message, source, aprError);
> }
>
> Should we allow ClientException to also be used for things outside of
> the native library?
Hmm, good point. JavaHL's exception code is not in a very good state
(e.g. some SVNAdmin APIs throw ClientException). ClientException was
originally only thrown by the native library. A while back, I
retrofitted the exception code a little bit with a generic
SubversionException super-class, and NativeException, and started
pushing "throws SubversionException" into new APIs to hide the exact
implementation.
While we could provide another constructor for ClientException which
doesn't require "source" and "aprError" parameters, it's still a
sub-class of NativeException, which isn't very appropriate for
exceptions thrown by non-native Java code.
I'm not sure what do here -- maybe make NativeException a helper class
instead of something which is sub-classed? Gah,
need..multiple..inheritance. I'll think on it.
public Status singleStatus(String path, boolean onServer)
throws ClientException
{
try
{
return status(path, false, onServer, true, false, false)[0];
}
catch (ArrayIndexOutOfBoundsException e)
{
// ### rethrow as ???
}
}
- application/pgp-signature attachment: stored
Received on Wed Mar 21 22:35:05 2007