Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

[Jeroen Vermeulen]

On 2014-05-30 15:08, roger peppe wrote:

>> Two: a caller can deal better with some errors, given more detailed
>> information.  You can help by attaching more information to the error (tags,
>> taxonomy, properties) but only on a best-effort basis.  You accept that you
>> don't know exactly which errors can come out of the code further down.
>
> This, on the other hand is interesting, and something I have not
> really considered. Thanks for bringing it up. I haven't written code like this,
> and I'm not aware of any in the juju-core code base.
>
> Have you got any real-world examples you could point to?

Usually it's mundane stuff.  I'm sure you're familiar with this and I 
just described in a way that made it harder to recognise!

Think of things like:

  * A broken-connection error can emerge from any of a number of places 
below this function call, but you've got a good way of handling them 
right after you come out of the call.  If you can't recognise the error 
for whatever reason, oh well, the user experience degrades a bit but you 
handle it as a generic program failure.

  * An IMAP client library annotates some kinds of errors with details 
about the command that failed.  It can't decide for you that you'll want 
those details in the error message, but you may still want to log them 
elsewhere.  You don't need that on a DNS lookup error, for example, so 
for that type of error you don't much care if you log the details or 
not.  It won't bother you if the library returns a different kind of 
error than before in some situations.

  * In some error situations a failed database transaction can be 
retried, and may well succeed next time.  This can save you a transient 
failure.  Of course it can be difficult to tell whether it's safe to do 
so.  Some types of database errors can say "retrying is safe as far as 
I'm concerned," but you default to failure.

  * You've been writing a file that could get quite large.  If you fail 
before you're done, you want to keep the data you have.  But if the 
error was "disk full," you prefer to clean up the output as a kindness 
to the user.

  * My systems management library calls a library called CoolApt to run 
the equivalent of apt-get update.  Your application uses my library.  It 
knows about the CoolApt "can't acquire packages lock" error and does a 
bit of investigating to provide a better explanation to the user.  When 
version 2.0 of my library replaces CoolApt with HotApt, you obviously 
want to upgrade.  The error is different, so this feature is temporarily 
broken — but you may find that acceptable.

These are all "quality of service" distinctions.  The effort of a more 
specific error is appreciated, but you can accept a certain amount of 
change.


Jeroen