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 >
