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 <markphip_at_gmail.com> wrote:
> On Tue, May 29, 2012 at 8:32 PM, Blair Zajac <blair_at_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/
>
Received on 2012-05-30 18:03:48 CEST