<div dir="ltr">This is a topic which interests me, so I decided to do a brief <a href="http://blog.kate.cox2.name/2014/07/an-argument-for-parameter-validation-im.html">blog post</a> expressing my views. I tried to address the points your brought up here.<div>
<br></div><div>The short of it is:</div><div><ol><li>Parameter validation is not constrained to checking for nils.</li><li>You don't know how values you are passed were constructed, and that statement only becomes more true over time.</li>
</ol><div>In the aforementioned case, we were breaking the law of demeter, and a property I was trying to reference on a constructed object's property (e.g. machineConfig.Config.ImageStream()) was -- intentionally -- nil. What I would usually do is plop a check at the head of the method to make sure this was not the case, and return an error if it were. In this case (and many cases), this would save a lot of high-cost work before getting to the error, i.e.: fail fast.</div>
</div><div><br></div><div>Hope this is interesting to you all.</div><div><br></div><div>-</div><div>Katherine</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 31, 2014 at 12:15 PM, Nate Finch <span dir="ltr"><<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In general, nil reference problems shouldn't happen as long as we're checking errors... for example:<div>
<br></div><div>foo, err := generateFoo()</div><div>if err != nil {</div><div> return err</div>
<div>}</div><div>// use non-nil foo</div><div><br></div><div>It would be interesting to see where the nil dereference happened, and how we got there without someone returning an error. That would seem to be a logic error of either someone not checking an error return, or someone not returning an error when they return nil. Unless it's just a developer error of forgetting to initialize a variable or something.</div>
<div><br></div><div>I'm not a huge fan of a bunch of these at the top of every function:</div><div><br></div><div>if foo == nil {</div><div> return errors.New("foo cannot be nil!")</div><div>}</div><div>
<br></div><div>When foo being nil should be impossible due to the contract of whatever function created it.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 31, 2014 at 11:17 AM, Katherine Cox-Buday <span dir="ltr"><<a href="mailto:katherine.cox-buday@canonical.com" target="_blank">katherine.cox-buday@canonical.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hey all,<div><br></div><div>What is the general consensus on parameter validation in Juju? As a general practice, I always like to see code that validates parameters passed into methods so that it fails fast, and gives future developers a contract to work off of.</div>
<div><br></div><div>Just yesterday I experienced a nil-reference panic which occurred after a lot of heavy operations. Parameter validation would have kicked me out much higher in the stack and given me some indication of what was wrong.</div>
<div><br></div><div>Always interested in discussion :)</div><div><br></div><div>-</div><div>Katherine</div></div>
<br></div></div><span class="HOEnZb"><font color="#888888">--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></font></span></blockquote></div><br></div>
</blockquote></div><br></div>