On 2014-05-29 09:50, roger peppe wrote:
On 29 May 2014 04:03, Tim Penhey <tim.pen...@canonical.com> wrote:
Errors are worth treating specially here because they're
they pass up through multiple layers, so it's very easy to break abstraction
boundaries by relying on specific error types. I believe it's very important
to *think* about the possible errors that can be returned from a given
function, and not just throw up our hands and say "you guys 5 layers down,
why don't you just communicate *arbitrary stuff* to the guy 3 layers above".
It may help to consider this as two problems.
One: caller needs to know about a specific failure — e.g. because it's a
failure to the callee but not to the caller. Definitely part of the
contract. You either:
(a) define a super-specific error (exception class, error code, etc.), or
(b) document that standard error X means failure Y in this case, and the
caller picks up the error as close as possible to its origin.
With these errors you have to make sure that the information isn't
diluted as it propagates, but usually you don't have to take it too far
up the call chain.
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.
For example, if you're writing code which speaks to another program over
the network, you may want to know: is this connection still usable? Do
I know what happened to the operation I requested? Were we able to
connect in the first place? Am I doing something that shouldn't ever
work, such as mis-spell a command?
With these errors you act on the best information you have, but you can
always just fail.
Jeroen
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
