class only describes the error type)
>> Personally, I think a good scheme is to have a hierarchy, but with maybe
>> only two levels: (1) the scope of the error, e.g. ConfigException, and (2)
>> the cause, e.g. ConfigExistsException.
>> Kanak
>>
>> ---
k a good scheme is to have a hierarchy, but with maybe
> only two levels: (1) the scope of the error, e.g. ConfigException, and (2)
> the cause, e.g. ConfigExistsException.
> Kanak
>
> --------
> > Date: Wed, 19 Feb 2014 22:24:12 -0800
>
istsException.
Kanak
> Date: Wed, 19 Feb 2014 22:24:12 -0800
> Subject: Re: Exceptions in Helix
> From: osgig...@gmail.com
> To: dev@helix.apache.org
>
> Hi Kanak,
>
> Like I said the first stab was to start a conversation. So what you are
> pointing at is defin
Hi Kanak,
Like I said the first stab was to start a conversation. So what you are
pointing at is defining an exception based on the API invoked. So a
NodeAlreadyExistsException can be thrown on an addNode API but that
exception should specialization of the ConfigException to clearly indicate
that
My concern with this hierarchy is that it does a good job of describing what
fails, but doesn't really hint at why. For instance, when trying to create a
cluster that already exists, we would get something like a
ClusterConfigException, and need to read javadocs to understand how it could be
th
