Parameter validation & Juju

[Nate Finch]

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/20140731/9e451e02/attachment.html>