<div dir="ltr">Brought up by a recent code review, I think it worth a thorough discussion about the error handling rule.<div><br></div><div>I once read an article[1] from Joyent and it impressed me on the distinguish between <b>Operational</b> errors vs. <b>programmer</b> errors. The article is written for nodejs, but the principle also applies for other programming language.</div><div><br></div><div>The basic rule recommended by Joyent is </div><div><h3 class="inbox-inbox-no" style="box-sizing:border-box;font-family:open-sans,sans-serif;font-weight:300;line-height:1.1;color:rgb(51,51,51);margin-top:22px;margin-bottom:11px;font-size:28px">Handling operational errors</h3></div><div><h3 class="inbox-inbox-no" style="box-sizing:border-box;font-family:open-sans,sans-serif;font-weight:300;line-height:1.1;color:rgb(51,51,51);margin-top:22px;margin-bottom:11px;font-size:28px">(Not) handling programmer errors</h3></div><div>There is also one rule in openstack style guide line[2] close to this idea.</div><div><br></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:14.4px">[H201] Do not write<span class="inbox-inbox-Apple-converted-space"> </span></span><code class="inbox-inbox-docutils inbox-inbox-literal" style="color:rgb(62,67,73)"><span class="inbox-inbox-pre">except:</span></code><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:14.4px">, use<span class="inbox-inbox-Apple-converted-space"> </span></span><code class="inbox-inbox-docutils inbox-inbox-literal" style="color:rgb(62,67,73)"><span class="inbox-inbox-pre">except</span><span class="inbox-inbox-Apple-converted-space"> </span><span class="inbox-inbox-pre">Exception:</span></code><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:14.4px"><span class="inbox-inbox-Apple-converted-space"> </span>at the very least. When catching an exception you should be as specific so you don’t mistakenly catch unexpected exceptions.</span><br></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:14.4px"><br></span></div><div><div>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.</div></div><div><br></div><div>So the question is <b>what kind of operational errors are we facing in vitrage?</b> I can think of something like</div><div><ol><li>invalid configuration file</li><li>failed to communicate with data source</li><li>malformed data from data source</li><li>failed to execute an action</li><li>...</li></ol><div>Maybe this could be the first step for the error handling design.</div></div><div><br></div><div>[1]: <a href="https://www.joyent.com/node-js/production/design/errors">https://www.joyent.com/node-js/production/design/errors</a></div><div>[2]: <a href="https://docs.openstack.org/developer/hacking/">https://docs.openstack.org/developer/hacking/</a></div><div><br></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">Yujun Zhang</div></div>