Merge lp://staging/~wallyworld/juju-core/consolidate-common-errors into lp://staging/~juju/juju-core/trunk

Reviewers: mp+166415_code.launchpad.net,

Message:
Please take a look.

Description:
Consolidate common error code

I need to do some work which involves using an UnauthorisedError.
There's
one defined, but on the state package. There's also two different
NotFound
error implementation - one in state and one in environs. These errors,
and
possibly others, should be in a common, generic package so they can be
used
across the code base. I've created an errors packge and moved the
structs
and associated help methods there eg IsNotFoundError(), NotFoundf() etc.

The changes are just mechanical and eliminate existing duplicate code.
But now in the next branch, I can reuse UnauthorisedError and avoid
defining another instance of this error.

https://code.launchpad.net/~wallyworld/juju-core/consolidate-common-errors/+merge/166415

(do not edit description out of merge proposal)

Please review this at https://codereview.appspot.com/9859045/

Affected files:
   A [revision details]
   M cmd/juju/upgradejuju.go
   M cmd/jujud/agent.go
   M cmd/jujud/agent_test.go
   M cmd/jujud/bootstrap_test.go
   M cmd/jujud/machine_test.go
   M cmd/jujud/unit_test.go
   M cmd/jujud/upgrade.go
   M environs/agent/agent.go
   M environs/dummy/storage.go
   M environs/ec2/ec2.go
   M environs/ec2/live_test.go
   M environs/ec2/storage.go
   M environs/imagemetadata/simplestreams.go
   M environs/interface.go
   M environs/jujutest/livetests.go
   M environs/jujutest/tests.go
   M environs/local/storage.go
   M environs/local/storage_test.go
   M environs/maas/environ_test.go
   M environs/maas/state_test.go
   M environs/maas/storage.go
   M environs/maas/storage_test.go
   M environs/openstack/provider.go
   M environs/openstack/storage.go
   M environs/storage.go
   M environs/tools.go
   M environs/tools_test.go
   A errors/errors.go
   M juju/conn.go
   M state/apiserver/api_test.go
   M state/apiserver/apierror.go
   M state/apiserver/client_test.go
   M state/apiserver/errors_test.go
   M state/apiserver/machine_test.go
   M state/apiserver/user.go
   M state/charm_test.go
   M state/constraints.go
   M state/environ.go
   M state/initialize_test.go
   M state/machine.go
   M state/machine_test.go
   M state/open.go
   M state/relation.go
   M state/relation_test.go
   M state/relationunit.go
   M state/relationunit_test.go
   M state/service.go
   M state/service_test.go
   M state/settings.go
   M state/settings_test.go
   M state/state.go
   M state/state_test.go
   M state/statecmd/destroyrelation_test.go
   M state/status.go
   M state/tools_test.go
   M state/unit.go
   M state/unit_test.go
   M state/user.go
   M state/watcher.go
   M worker/deployer/deployer.go
   M worker/deployer/deployer_test.go
   M worker/firewaller/firewaller.go
   M worker/machiner/machiner.go
   M worker/provisioner/provisioner.go
   M worker/provisioner/provisioner_test.go
   M worker/uniter/filter.go
   M worker/uniter/modes.go
   M worker/uniter/relationer_test.go
   M worker/uniter/uniter.go
   M worker/uniter/uniter_test.go

LGTM

I'm happy with this, and it is certainly the route we went with in
goose. However, I'm probably not the one you need to convince. :)

https://codereview.appspot.com/9859045/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-05-30 8:19, <email address hidden> wrote:
> LGTM.
>
> I will add a note of sadness that the import list at the top of
> most of our files is starting to resemble java in its verbosity.
> While not directly related this proposal, I do see it as a result
> of trying to define our packages at a very fine level of
> granuality; above what I believe is necessary.
>
Isn't that the Unix philosophy? Small focused bits of functionality,
that you can reuse and combine into something useful?

It also seems to be espoused in the Go documents that *I've* read.
That you should have things like

one.New()
two.New()

rather than

all.NewOne()
all.NewTwo()

A clear example of this is something like:
  http://golang.org/pkg/encoding/

Where every encoding is its own sub-package, rather than one package
that has bits for each thing.

If you can give rough outlines of what you think it should look like,
I'd certainly be interested to hear about it.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGm11kACgkQJdeBCYSNAANt1ACgj7ImjrWjwpDLoXmmUF0/dtzV
hWAAoJiTL7E073YkMdhSKNLOzdt7M1ds
=x6AD
-----END PGP SIGNATURE-----

*** Submitted:

Consolidate common error code

I need to do some work which involves using an UnauthorisedError.
There's
one defined, but on the state package. There's also two different
NotFound
error implementation - one in state and one in environs. These errors,
and
possibly others, should be in a common, generic package so they can be
used
across the code base. I've created an errors packge and moved the
structs
and associated help methods there eg IsNotFoundError(), NotFoundf() etc.

The changes are just mechanical and eliminate existing duplicate code.
But now in the next branch, I can reuse UnauthorisedError and avoid
defining another instance of this error.

R=jameinel, dfc
CC=
https://codereview.appspot.com/9859045

https://codereview.appspot.com/9859045/diff/1/cmd/juju/upgradejuju.go
File cmd/juju/upgradejuju.go (right):

https://codereview.appspot.com/9859045/diff/1/cmd/juju/upgradejuju.go#newcode7
cmd/juju/upgradejuju.go:7: "errors"
On 2013/05/30 04:19:13, dfc wrote:
> import stderrors "errors"

Done.

https://codereview.appspot.com/9859045/