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
