Brought up by a recent code review, I think it worth a thorough discussion about the error handling rule.
I once read an article[1] from Joyent and it impressed me on the distinguish between *Operational* errors vs. *programmer* errors. The article is written for nodejs, but the principle also applies for other programming language. The basic rule recommended by Joyent is Handling operational errors (Not) handling programmer errors There is also one rule in openstack style guide line[2] close to this idea. [H201] Do not write except:, use except Exception: at the very least. When catching an exception you should be as specific so you don’t mistakenly catch unexpected exceptions. I do think before we have a well designed error handling, it is better to let it crash. It is dangerous to hide the errors and keep the system running in undetermined states. So the question is *what kind of operational errors are we facing in vitrage?* I can think of something like 1. invalid configuration file 2. failed to communicate with data source 3. malformed data from data source 4. failed to execute an action 5. ... Maybe this could be the first step for the error handling design. [1]: https://www.joyent.com/node-js/production/design/errors [2]: https://docs.openstack.org/developer/hacking/ -- Yujun Zhang
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev