A home for underappreciated errors

[Dimiter Naydenov]

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

On 10.02.2015 11:57, roger peppe wrote:
> On 10 February 2015 at 08:55, Andrew Wilkins 
> <andrew.wilkins at canonical.com> wrote:
>> Hi all,
>> 
>> Ian raised a good point in http://reviews.vapour.ws/r/885/
>> (caution advised, may cause eyebleed) about a change I made to
>> errors: https://github.com/juju/errors/pull/17
>> 
>> The NotAssigned error, which previously was only raised by 
>> state.Unit.AssignedMachineId, is now also raised by 
>> state.Volume.StorageInstance. I removed the error from the state
>> package so we didn't have apiserver/common poking its head in
>> there, and moved it over to the juju/errors package.
>> 
>> The issue Ian raised is that juju/errors should contain
>> relatively generic error types, and we should keep
>> domain-specific things elsewhere. Examples are NotAssigned, and
>> NotProvisioned. We're thinking of moving these domain-specific
>> error types into a new package, juju/juju/errors. What do you
>> think about this?
NotAssigned is more generic than NotProvisioned IMO, so if I were to
decide which one to move to juju/errors, I'd move the former, not the
latter.

> 
> I agree with Ian here. Personally, I think that specific error 
> types/values work well when defined in or close to the module that
> returns them, which is aligned to my general feeling that the set
> of possible returned errors is part of the contract of the method
> it was returned from.
> 
> For example, the mgo package returns mgo.ErrNotFound when an item
> isn't found, and that's fine - we translate from that error to a
> more local not-found error when necessary.
> 
> For errors that pass over an API, they can be considered a part of
> the API and defined along with the other API types.
> 
> So, rather than a single package for juju-related errors, I would
> suggest that domain-specific errors are defined in packages close
> to the domain in question rather than in a single package used by
> everything. To my mind this is a more modular and scalable
> approach.
> 
+1 I like the idea of having state/errors for
sharable-but-domain-specific errors (or network/errors,
storage/errors, etc.) and leave generic errors useful it a lot more
cases in juju/errors.

> It's also the standard Go idiom.
> 
> cheers, rog.
> 


- -- 
Dimiter Naydenov <dimiter.naydenov at canonical.com>
Juju Core Sapphire team <http://juju.ubuntu.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU2d83AAoJENzxV2TbLzHwd20H/i22GBC5dADZnLFAfNhE+X0y
E7tZc+UkrsKGUmcAHm1k5tEuv3r9Vk6vLxtEcRVXcWvXqoCCW72Cpsw7lLiAkKoH
dYPwyBTVorp/N+Z1hxMN+P3LhctRlGNlz1IR9BLJ+3fM/Dlfp+YfVJ93BfqrcC7f
uaUJY0iSdOHuedfs29CtTtamSDNb1s3l8uCo5X0Ihh2zc1SMOHPVFxrdWnLTERpN
Vw8C6gv47GETUekTzwoviioiQrDxKijMqjkGB9khrKiXdlSLz0rQV2W+874ztPgo
pkcdlSzLCJ89r7WB79kajGYWGrlXD1n6NsTSgywIW+M8teIprHjR/exWDxtyPKs=
=dbEQ
-----END PGP SIGNATURE-----