On 29 May 2014 04:03, Tim Penhey <tim.pen...@canonical.com> wrote:
> On 29/05/14 01:11, roger peppe wrote:
>> Writing code to explicitly declare function return types is also
>> a perpetual drag on refactoring, but it's also incredibly useful.
>>
>> The set of possible returned errors *should* be part of the contract
>> of a function, otherwise how could you know that a given error might
>> be returned?
>
> This theory has also been applied to both Java and C++ in the past with
> checked error types, and in both situations it ended up being unworkable
> and discarded by both communities.
There's a huge difference between adding errors formally as part
of the type system and checking them as part of the runtime.
The latter is indeed unworkable because you end up with a proliferation
of method signatures that cannot work together. The former is
more like a domain-specific form of Eiffel's postconditions.
To put it another way, we don't try to encode the fact that math.Sqrt
returns the square root of a number in its type signature. But that
fact is definitely part of the contract of the function, and we write
tests for it.
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".
That already happens, and it has resulted in real bugs.
The errgo stuff is trying to be a way of communicating that thinking
in code and it defaults to a mode that closes off those arbitrary communication
channels by default, reducing the overall complexity of the system.
I am by no means saying that the errgo interface is perfect, or even
particularly
great - the API design feels cluttered and unnecessarily complex
even though the code is quite simple. But I stand by that aspect of the design.
cheers,
rog.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
