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 15:06:11 CEST