tree 5571bada6c4e47035729f18e77e681c43cdd59f0
parent 95530b644002bbfba093d2b00aa53922d0f07b96
author Mike Burrows <m3b@google.com> 1418839279 -0800
committer Mike Burrows <m3b@google.com> 1418839288 -0800

veyron.io/veyron/veyron/services/mgmt: Update to use verror2

This changes files within veyron.io/veyron/veyron/services/mgmt to use verror2
rather than verror.

There is one exception:
        veyron.io/veyron/veyron/services/mgmt/node/impl/util_test.go
still uses both verror and verror2 (and is not altered by this change).  That's
because it uses verror.ID.  verror2 uses the same type, and its name will not
change when verror2 is renamed to be verror.

In many files, the import of verror2 renames the package locally to be verror,
to make the future renaming of verror2 easier.

Beware that the tests in veyron.io/veyron/veyron/services/mgmt/node/impl
require that the environment variable VEYRON_CREDENTIALS not be set.

                        --------------------

There is a trade off between using a new error code defined by the local module,
and using a standard error code (defined by verror, say). In the former case, one gets
to pick precisely the error message one wishes; in the latter case, one gets to
reuse an error code (such as verror.NoExist) that may be familiar to clients,
but the error message is the standard one (so it can be internationalized).

I chose to reuse existing error codes when it seemed appropriate, even when
that means that the error message will be somewhat less informative.  For
example, in veyron.io/veyron.io/veyron/services/mgmt/binary/impl/fs_utils.go I
elected to continue to use verror.NoExist, leading to the error message (in
English) "Does not exist" rather than the previous error message "binary not
found".  If you think I should use a different error code in order to make the
error messages suit the context better, let me know.

Change-Id: I52d99488c63bb98c3a4491415ddf5a74957c0918