On 16.03.2015 17:54, Bert Huijben wrote:
> A fix for this generic problem has been applied to trunk in r1664938 (further tweaks/extensions in 1664939,1664940,1664978,1664984).
Great -- this is exactly what I was looking for.
> This introduces some behavior changes (such as the one you noted), so backporting needs discussion here. Thanks for starting the discussion ;-)
Silently dropping an exception and continuing to process the operation
is quite unexpected. Hence, this could be considered as bugfix instead
of behavior change :)
SVNKit usually allows to return a SubversionException from its various
callbacks. As far as I understand your patch, it delivers the same
Exception object which is thrown in Java code (possibly wrapped). So
extending JavaHL's callback signatures by SubversionException would be
reasonable, too. Use cases are mainly to deliver checked
ProgressCancelledExceptions.
-Marc
On 16.03.2015 17:54, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Marc Strapetz [mailto:marc.strapetz_at_syntevo.com]
>> Sent: maandag 16 maart 2015 17:30
>> To: dev_at_subversion.apache.org
>> Subject: JavaHL: Exceptions in LogMessageCallback.singleMessage should abort
>> the log immediately
>>
>> If e.g. a RuntimeException is thrown in
>> LogMessageCallback#singleMessage, it's not processed in
>> LogMessageCallback::singleMessage and the log is continued nevertheless:
>>
>> (1) At line 77 in LogMessageCallback.cpp, there should be returned an
>> appropriate error code.
>>
>> (2) After line 122, JNIUtil::isJavaExceptionThrown() should be called
>> and there should be returned an appropriate error code.
>>
>> In both cases, the returned error code should result in stopping the
>> low-level log; rethrowing the Exception in RemoteSession::getLog won't
>> be necessary, as this can be established easily from within client code
>> itself.
>
> This is a common problem that applies to almost all callbacks in JavaHL in <= 1.9.
>
> A fix for this generic problem has been applied to trunk in r1664938 (further tweaks/extensions in 1664939,1664940,1664978,1664984).
>
> This introduces some behavior changes (such as the one you noted), so backporting needs discussion here. Thanks for starting the discussion ;-)
>
> Bert
>
>
>
Received on 2015-03-16 23:13:13 CET