Hi Kanak, Thanks for the background but I am sure you will agree that as a Java API it looks broken if I catch RuntimeExceptions and then assume that nothing went wrong and proceed to create the instance configuration.
I will do exactly that (catch Runtime exception) for now but maybe the take-away is to log a debt ticket to resolve it and provide a cleaner API in the near future. Let me know if there is anything I can do to help be it logging the ticket or helping out with the API if there is a venue to iron out the exception hierarchies. Thanks, Sandeep On Tue, Feb 18, 2014 at 10:21 PM, Kanak Biscuitwala <[email protected]>wrote: > Hi Sandeep, > > Mostly for compatibility and historical reasons. Also, many Helix systems > typically run HelixAdmin via the REST or command line API, so in those > cases, a loud failure is more natural. > > We've wanted to add checked exceptions for some time now, but haven't had > the cycles to take the time and really get it right. > > Kanak > ________________________________ > > Date: Tue, 18 Feb 2014 22:15:53 -0800 > > Subject: HelixAdmin API Usage > > From: [email protected] > > To: [email protected] > > > > Hi, > > > > Prior to adding an instance config to a cluster I am trying to check if > > there exists such a configuration already using > > ZKHelixAdmin.getInstanceConfig. I found that it throws a > > RuntimeException as against returning a null or throwing a checked > > exception. > > > > I think the use-case of wanting to know if an instance is already > > existent in the cluster and if not adding one seems common. Throwing a > > RuntimeException indicates a condition that the system cannot handle, a > > checked exception on the other hand would be more appropriate so that > > the invoker of getInstanceConfig can take an action to remedy the lack > > of configuration by creating it. > > > > Is there a reason for the RuntimeException? > > > > Thanks, > > > > Sandeep >
