Parameter validation & Juju
Katherine Cox-Buday
katherine.cox-buday at canonical.com
Mon Aug 4 13:46:16 UTC 2014
This is a topic which interests me, so I decided to do a brief blog post
<http://blog.kate.cox2.name/2014/07/an-argument-for-parameter-validation-im.html>
expressing my views. I tried to address the points your brought up here.
The short of it is:
1. Parameter validation is not constrained to checking for nils.
2. You don't know how values you are passed were constructed, and that
statement only becomes more true over time.
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.
Hope this is interesting to you all.
-
Katherine
On Thu, Jul 31, 2014 at 12:15 PM, Nate Finch <nate.finch at canonical.com>
wrote:
> In general, nil reference problems shouldn't happen as long as we're
> checking errors... for example:
>
> foo, err := generateFoo()
> if err != nil {
> return err
> }
> // use non-nil foo
>
> 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.
>
> I'm not a huge fan of a bunch of these at the top of every function:
>
> if foo == nil {
> return errors.New("foo cannot be nil!")
> }
>
> When foo being nil should be impossible due to the contract of whatever
> function created it.
>
>
> On Thu, Jul 31, 2014 at 11:17 AM, Katherine Cox-Buday <
> katherine.cox-buday at canonical.com> wrote:
>
>> Hey all,
>>
>> 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.
>>
>> 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.
>>
>> Always interested in discussion :)
>>
>> -
>> Katherine
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140804/b9d55397/attachment.html>
More information about the Juju-dev
mailing list