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
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
