Agreed. Work on a more Java-friendly admin API is already underway in the 0.7 
branch and it's something that's high on the list for the next release.

Kanak

________________________________
> Date: Tue, 18 Feb 2014 22:27:56 -0800 
> Subject: Re: HelixAdmin API Usage 
> From: [email protected] 
> To: [email protected] 
> 
> 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]<mailto:[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]<mailto:[email protected]> 
>> To: [email protected]<mailto:[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 
>                                         

Reply via email to