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 thrown. An alternative is to create exceptions based on error type, like ExistsException or something.
Anyone else have thoughts? > Date: Wed, 19 Feb 2014 21:48:00 -0800 > Subject: Exceptions in Helix > From: [email protected] > To: [email protected] > > Hi guys, > > I sent out a mail last night (on the users maillist) that currently > Instance configuration retrieval from HelixAdmin throws HelixException > which is a runtime exception. > > I did not want to create a whole exception hierarchy for every API given my > narrow scope of understanding but wanted to illustrate an exception > hierarchy focussed on the above aspect and maybe influence an exception > hierarchy design which I am hoping someone who has a better grasp on the > entire codebase can pick and flesh out further. > > I looked at https://cwiki.apache.org/confluence/display/HELIX/API+Redesign and > saw the configuration hierarchy. > > So given that context here is my first stab at the Helix configuration > exception hierarchy. > > > - *HelixException //**This is base for all checked exceptions in Helix* > - *HelixConfigException* extends HelixException //This represents > checked exception hierarchy for configuration exceptions > - *HelixResourceConfigException* extends HelixConfigException > - *HelixStateModelConfigException* extends HelixConfigException > - *HelixInstanceConfigException* extends HelixConfigException > //Config exception specific to instances being added > - *HelixSpectatorConfigException* extends > HelixNodeConfigException //Specialized exceptions for types *if > applicable or necessary* > - *HelixParticipantConfigException* extends > HelixNodeConfigException //Specialized exceptions for types *if > applicable or necessary* > - *HelixControllerConfigException* extends > HelixNodeConfigException //Specialized exceptions for types *if > applicable or necessary* > - Other Checked Exceptions which are non-config but identify other > aspects of Helix which represent distinct subsets of functionality, like > the above represents configuration part. > - *HelixRuntimeException //**Base for all exceptions from which Helix > cannot recover* > - All derived classes which are failures which cannot be recovered > from > > Again I am throwing this out to start a conversation and maybe influence a > design approach for exceptions in future releases. I apologize for not > spending time on drawing a neat diagram, I decided to something out sooner > rather than wait until I got together a pretty diagram. > > Hopefully, you guys get an idea of what I am trying to convey. Feel free to > send questions if you want clarity on my suggestion, but please recognize > that its only been less than a week that I have looked at Helix so I hope > you won't expect me to chalk up the entire hierarchy :-) I think one of you > guys who has worked on the codebase for sometime may be better suited. I > can certainly help review and/or fine-tune and in the process learn Helix > internals a bit more. > > Thanks, > > Sandeep
