You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by vm...@apache.org on 2012/05/18 23:12:26 UTC
svn commit: r1340253 - /subversion/trunk/COMMITTERS
Author: vmpn
Date: Fri May 18 21:12:26 2012
New Revision: 1340253
URL: http://svn.apache.org/viewvc?rev=1340253&view=rev
Log:
* COMMITTERS: Added myself as partial committer for the javahl-ra branch
Modified:
subversion/trunk/COMMITTERS
Modified: subversion/trunk/COMMITTERS
URL: http://svn.apache.org/viewvc/subversion/trunk/COMMITTERS?rev=1340253&r1=1340252&r2=1340253&view=diff
==============================================================================
--- subversion/trunk/COMMITTERS [UTF-8] (original)
+++ subversion/trunk/COMMITTERS [UTF-8] Fri May 18 21:12:26 2012
@@ -201,6 +201,7 @@ giorgio_valoti Giorgio Valoti <giorgio
br.)
holden Holden Karau <ho...@pigscanfly.ca> (scheme-bindings br.)
moklo Morten Kloster <mo...@gmail.com> (diff-improvements br.)
+ vmpn Vladimir Berezniker <vm...@hitechman.com> (javahl-ra br.)
Subprojects that are complete, abandoned or have moved elsewhere:
Re: svn commit: r1340253 - /subversion/trunk/COMMITTERS
Posted by Vladimir Berezniker <vm...@hitechman.com>.
To be clear, for now I am only proposing this for the new RA APIs. I would
keep existing SVNClient and SVNRepos as is, because of backwards
compatibility. However, given large amount of shared code this might not be
practical.
Yes, I propose that checked exceptions would be used in cases when client
is expected to deal with the error. But in practice I am not aware of such
case yet. Also if there is expected recovery path, it is possible that it
would make sense to include this error handling in the library itself.
As to sending a separate email, let me implement first version with same
exceptions as SVNClient and then convert to unchecked as the next logical
step. This will allow me to better understand impact on the code base.
Thank you,
Vladimir
On Tue, May 29, 2012 at 8:32 PM, Blair Zajac <bl...@orcaware.com> wrote:
> On 05/21/2012 04:18 AM, Vladimir Berezniker wrote:
>
>> Hyrum,
>>
>>
>> 4. Use runtime rather than checked exceptions.
>>
>> I strongly dislike checked exceptions in code paths where there is
>> no expected recovery logic that can be applied. This just forces people
>> to either write a lot of try catch blocks that don't have any useful
>> logic, propagate the exceptions through all the methods, or catch and
>> wrap the exception in a RuntimeException derived class.
>>
>
> I don't know if any of the other JavaHL coders saw this note, so I suggest
> sending a separate email with a descriptive subject "Switching to unchecked
> Java exceptions" since it is a significant change in the API and some other
> people may want to have a say.
>
> I do think it's a good idea when there is no action that the caller can do
> to recover. I cannot think of any drawbacks right now, and in our own
> non-svn Scala code we effectively use unchecked exceptions (because Scala
> doesn't do compile time checking if an exception is handled).
>
> You're proposing keeping checked exceptions when the caller can do
> something?
>
> Blair
>
Re: svn commit: r1340253 - /subversion/trunk/COMMITTERS
Posted by Vladimir Berezniker <vm...@hitechman.com>.
1. I only plan to make this change for RA API. The change to existing code
is a different question and I think it should be left alone because of
backwards compatibility.
2. Code can still catch the runtime exception derived from
SubversionRuntimeException just like it does with the checked exception.
3. Java has NullPointerException, ConcurrentModificationException,
IllegalArgumentExcption, FileSystemNotFoundException and many other ones.
They can be thrown by core java libraries at unexpected times. While
carefuly written code minimizes the risk of these occurring they still
happen. So if a particular use case requires that java code is robust in
light of exceptions, catching RuntimeException is probably a good idea. On
the flip side there are use cases where letting the application fail is
also fine.
With checked exceptions in both use cases you have to write code in every
path where exception might occur whether you care or not.
With runtime exceptions you can still catch the same exception. But you can
also do that in a single place or not at all.
Regards,
Vladimir
On Wednesday, May 30, 2012, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, May 29, 2012 at 8:32 PM, Blair Zajac <bl...@orcaware.com> wrote:
>> On 05/21/2012 04:18 AM, Vladimir Berezniker wrote:
>>>
>>> Hyrum,
>>>
>>> 4. Use runtime rather than checked exceptions.
>>>
>>> I strongly dislike checked exceptions in code paths where there is
>>> no expected recovery logic that can be applied. This just forces people
>>> to either write a lot of try catch blocks that don't have any useful
>>> logic, propagate the exceptions through all the methods, or catch and
>>> wrap the exception in a RuntimeException derived class.
>>
>>
>> I don't know if any of the other JavaHL coders saw this note, so I
suggest
>> sending a separate email with a descriptive subject "Switching to
unchecked
>> Java exceptions" since it is a significant change in the API and some
other
>> people may want to have a say.
>>
>> I do think it's a good idea when there is no action that the caller can
do
>> to recover. I cannot think of any drawbacks right now, and in our own
>> non-svn Scala code we effectively use unchecked exceptions (because Scala
>> doesn't do compile time checking if an exception is handled).
>>
>> You're proposing keeping checked exceptions when the caller can do
>> something?
>
> I do not understand the proposal or the ramifications. As a consumer
> in a GUI tool I would be pretty pissed if SVN started throwing
> RuntimeExceptions though. Currently, we can catch exceptions and do
> something like show the user an intelligent error etc. Maybe those
> are not the sort of exceptions you plan on replacing though. As long
> as the client API usage stays the same, I do not necessarily care as I
> do not have any plans to use the RA API. For all I know, what you are
> proposing makes perfect sense in that context.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Re: svn commit: r1340253 - /subversion/trunk/COMMITTERS
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, May 29, 2012 at 8:32 PM, Blair Zajac <bl...@orcaware.com> wrote:
> On 05/21/2012 04:18 AM, Vladimir Berezniker wrote:
>>
>> Hyrum,
>>
>> 4. Use runtime rather than checked exceptions.
>>
>> I strongly dislike checked exceptions in code paths where there is
>> no expected recovery logic that can be applied. This just forces people
>> to either write a lot of try catch blocks that don't have any useful
>> logic, propagate the exceptions through all the methods, or catch and
>> wrap the exception in a RuntimeException derived class.
>
>
> I don't know if any of the other JavaHL coders saw this note, so I suggest
> sending a separate email with a descriptive subject "Switching to unchecked
> Java exceptions" since it is a significant change in the API and some other
> people may want to have a say.
>
> I do think it's a good idea when there is no action that the caller can do
> to recover. I cannot think of any drawbacks right now, and in our own
> non-svn Scala code we effectively use unchecked exceptions (because Scala
> doesn't do compile time checking if an exception is handled).
>
> You're proposing keeping checked exceptions when the caller can do
> something?
I do not understand the proposal or the ramifications. As a consumer
in a GUI tool I would be pretty pissed if SVN started throwing
RuntimeExceptions though. Currently, we can catch exceptions and do
something like show the user an intelligent error etc. Maybe those
are not the sort of exceptions you plan on replacing though. As long
as the client API usage stays the same, I do not necessarily care as I
do not have any plans to use the RA API. For all I know, what you are
proposing makes perfect sense in that context.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn commit: r1340253 - /subversion/trunk/COMMITTERS
Posted by Blair Zajac <bl...@orcaware.com>.
On 05/21/2012 04:18 AM, Vladimir Berezniker wrote:
> Hyrum,
>
> 4. Use runtime rather than checked exceptions.
>
> I strongly dislike checked exceptions in code paths where there is
> no expected recovery logic that can be applied. This just forces people
> to either write a lot of try catch blocks that don't have any useful
> logic, propagate the exceptions through all the methods, or catch and
> wrap the exception in a RuntimeException derived class.
I don't know if any of the other JavaHL coders saw this note, so I
suggest sending a separate email with a descriptive subject "Switching
to unchecked Java exceptions" since it is a significant change in the
API and some other people may want to have a say.
I do think it's a good idea when there is no action that the caller can
do to recover. I cannot think of any drawbacks right now, and in our
own non-svn Scala code we effectively use unchecked exceptions (because
Scala doesn't do compile time checking if an exception is handled).
You're proposing keeping checked exceptions when the caller can do
something?
Blair
Re: svn commit: r1340253 - /subversion/trunk/COMMITTERS
Posted by Vladimir Berezniker <vm...@hitechman.com>.
Hyrum,
I was thinking of adding, what I have implemented so far, on top of the
existing branch as there is minimal overlap and I would like to incorporate
the existing work. Therefore, my plan is to do the following,
not necessarily in the below order:
1. Rename SVNReposNaming to SVNRa.
I have used the variations of SVNRa for the C++ and java classes
related to the svn_ra_session_t as it conveys the meaning (IMHO) yet
remains short. I realize that A should have been capital too, but SVNRA
looks too much like a java constant and SvnRA is not consistent with
SVNClient.
2. Create objects in C++ returning jobjects to the calling code.
In my approach object creation is done in the C++ code rather than
having it split between Java and C++. It felt to me as cleaner to have it
in one place rather than split between java and C++. You can see the code
for that in SVNRaFactory.java in patch 18 and
org_apache_subversion_javahl_ra_SVNRaFactory.cpp in patch 20
3. Use longs in native function calls where apr_time_t is used to
avoid 2359<http://subversion.tigris.org/issues/show_bug.cgi?id=2359>
and
a wrapper function that uses Data and change GetDateRevision method
accordingly.
4. Use runtime rather than checked exceptions.
I strongly dislike checked exceptions in code paths where there is
no expected recovery logic that can be applied. This just forces people to
either write a lot of try catch blocks that don't have any useful logic,
propagate the exceptions through all the methods, or catch and wrap the
exception in a RuntimeException derived class.
5. Apply patches, updated to be compatible with existing code on the branch
(except the class naming)
If I should adjust my approach please let me know.
Thank you,
Vladimir
On Sat, May 19, 2012 at 1:23 AM, Hyrum K Wright
<hy...@wandisco.com>wrote:
> Vladimir,
> Feel free to delete the existing branch and start a new one for your
> work. Your patches look to be much more complete than what exists on
> the branch now.
>
> -Hyrum
>
> On Fri, May 18, 2012 at 4:12 PM, <vm...@apache.org> wrote:
> > Author: vmpn
> > Date: Fri May 18 21:12:26 2012
> > New Revision: 1340253
> >
> > URL: http://svn.apache.org/viewvc?rev=1340253&view=rev
> > Log:
> > * COMMITTERS: Added myself as partial committer for the javahl-ra branch
> >
> > Modified:
> > subversion/trunk/COMMITTERS
> >
> > Modified: subversion/trunk/COMMITTERS
> > URL:
> http://svn.apache.org/viewvc/subversion/trunk/COMMITTERS?rev=1340253&r1=1340252&r2=1340253&view=diff
> >
> ==============================================================================
> > --- subversion/trunk/COMMITTERS [UTF-8] (original)
> > +++ subversion/trunk/COMMITTERS [UTF-8] Fri May 18 21:12:26 2012
> > @@ -201,6 +201,7 @@ giorgio_valoti Giorgio Valoti <giorgio
> > br.)
> > holden Holden Karau <ho...@pigscanfly.ca>
> (scheme-bindings br.)
> > moklo Morten Kloster <mo...@gmail.com>
> (diff-improvements br.)
> > + vmpn Vladimir Berezniker <vm...@hitechman.com>
> (javahl-ra br.)
> >
> > Subprojects that are complete, abandoned or have moved elsewhere:
> >
> >
> >
>
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
>
Re: svn commit: r1340253 - /subversion/trunk/COMMITTERS
Posted by Hyrum K Wright <hy...@wandisco.com>.
Vladimir,
Feel free to delete the existing branch and start a new one for your
work. Your patches look to be much more complete than what exists on
the branch now.
-Hyrum
On Fri, May 18, 2012 at 4:12 PM, <vm...@apache.org> wrote:
> Author: vmpn
> Date: Fri May 18 21:12:26 2012
> New Revision: 1340253
>
> URL: http://svn.apache.org/viewvc?rev=1340253&view=rev
> Log:
> * COMMITTERS: Added myself as partial committer for the javahl-ra branch
>
> Modified:
> subversion/trunk/COMMITTERS
>
> Modified: subversion/trunk/COMMITTERS
> URL: http://svn.apache.org/viewvc/subversion/trunk/COMMITTERS?rev=1340253&r1=1340252&r2=1340253&view=diff
> ==============================================================================
> --- subversion/trunk/COMMITTERS [UTF-8] (original)
> +++ subversion/trunk/COMMITTERS [UTF-8] Fri May 18 21:12:26 2012
> @@ -201,6 +201,7 @@ giorgio_valoti Giorgio Valoti <giorgio
> br.)
> holden Holden Karau <ho...@pigscanfly.ca> (scheme-bindings br.)
> moklo Morten Kloster <mo...@gmail.com> (diff-improvements br.)
> + vmpn Vladimir Berezniker <vm...@hitechman.com> (javahl-ra br.)
>
> Subprojects that are complete, abandoned or have moved elsewhere:
>
>
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/