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

On 2014-05-30 19:56, roger peppe wrote: Both of the above seem like the code would be much more understandable and maintainable if the error kinds were documented and explicitly maintained by the libraries in question. Otherwise you end up with a big risk that you've got all this crufty code writ

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

On 30 May 2014 17:24, Jeroen Vermeulen wrote: > 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

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

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

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

On 29 May 2014 20:00, Jeroen Vermeulen wrote: > On 2014-05-29 09:50, roger peppe wrote: >> >> On 29 May 2014 04:03, Tim Penhey 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

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

On 29 May 2014 21:48, William Reade wrote: > Masking is often necessary, and information hiding is valuable, and > depending on spooky action at a distance is generally foolish. But the > granularity with which we want to track the propagation of a given error is > *much* finer than the granularit

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

Masking is often necessary, and information hiding is valuable, and depending on spooky action at a distance is generally foolish. But the granularity with which we want to track the propagation of a given error is *much* finer than the granularity of judicious information hiding: the error is like

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

Note that this kind of error masking doesn't need to be done in the same package as the base error package. I made a little standalone package that does it, we could do something similar if we wanted to keep the error package simpler (which is always

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

What Roger is talking about, is when an error is implementation-specific and may change if the implementation changes. For example, if you have a black box service that saves data, it might write to the network or it might write to a filesystem, but where it saves is an implementation detail. Let

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

On 2014-05-29 09:50, roger peppe wrote: On 29 May 2014 04:03, Tim Penhey 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

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

On 28 May 2014 19:40, Nate Finch wrote: > I think the main problem with errgo as it exists, is that it is very awkward > to allow error type information to pass through: > > return errgo.Mask(err, errgo.Any) > > This line is very misleading. It's saying - mask the error type, except > wait,

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

On 29 May 2014 04:03, Tim Penhey 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

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

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

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

I propose we change the name of the package to something other than errgo, so that Roger can keep his name, and we can make the behavior whatever fits best for Juju. Yes, we should make it a general-use package, but it should be designed for Juju, meeting our needs. Roger can post errgo wherever

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

I haven't seen any code or a description of what you're doing, so it's really hard for me to help. Broadly, what are you trying to accomplish? Maybe we can help avoid the need to do something that Go doesn't support well. On Tue, May 27, 2014 at 9:43 PM, Tim Penhey wrote: > On 28/05/14 13:31,

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

I just saw this thread after replying to the other one. Fundamentally, I think comparing errors for equality is misguided. That said, a simple approach that doesn't use DeepEquals is possible: func sameError(e1, e2 error) bool { defer func() { recover() }() return e1 == e2 } On 28 May 201

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

On 28 May 2014 00:46, William Reade wrote: > Roger > > We have had many long discussions, and you have provided much valuable > input: in particular, explaining to us that we were completely off-base re: > the attempts to use a slice vs a linked list in the error stacks. And we did > indeed agree

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

On 28/05/14 15:48, John Meinel wrote: > I think we need concrete examples which Tim should have in the test suite. > > John > =:-> > > On May 28, 2014 6:50 AM, "Andrew Wilkins" > wrote: > > On Wed, May 28, 2014 at 10:39 AM, John Meinel > mailto:j...@

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

I think we need concrete examples which Tim should have in the test suite. John =:-> On May 28, 2014 6:50 AM, "Andrew Wilkins" wrote: > On Wed, May 28, 2014 at 10:39 AM, John Meinel wrote: > >> The address of the real value is the same. >> > Are you referring to the backing array? That is not wh

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

On Wed, May 28, 2014 at 10:39 AM, John Meinel wrote: > The address of the real value is the same. > Are you referring to the backing array? That is not what is being compared, so that's not a useful property. > John > =:-> > On May 28, 2014 6:04 AM, "Andrew Wilkins" > wrote: > >> On Wed, May 28,

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

The address of the real value is the same. John =:-> On May 28, 2014 6:04 AM, "Andrew Wilkins" wrote: > On Wed, May 28, 2014 at 9:52 AM, Tim Penhey wrote: > >> On 28/05/14 13:48, Andrew Wilkins wrote: >> > On Wed, May 28, 2014 at 8:47 AM, Tim Penhey > > > wrote:

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

On Wed, May 28, 2014 at 9:52 AM, Tim Penhey wrote: > On 28/05/14 13:48, Andrew Wilkins wrote: > > On Wed, May 28, 2014 at 8:47 AM, Tim Penhey > > wrote: > > > > On 28/05/14 12:43, Nate Finch wrote: > > > This sounds like one of those "if you have to ask th

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

On 28/05/14 13:48, Andrew Wilkins wrote: > On Wed, May 28, 2014 at 8:47 AM, Tim Penhey > wrote: > > On 28/05/14 12:43, Nate Finch wrote: > > This sounds like one of those "if you have to ask this question, > you're > > doing something wrong". >

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

On Wed, May 28, 2014 at 8:47 AM, Tim Penhey wrote: > On 28/05/14 12:43, Nate Finch wrote: > > This sounds like one of those "if you have to ask this question, you're > > doing something wrong". > > > > Can you give an example of where we need this? > > Sure... let's say we have a stack of errors,

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

On 28/05/14 13:31, Nate Finch wrote: > If you're talking about errgo, if all we care about is transition, but > not what the actual types are, we could just record in the list when we > mask the type. We could, but that would mean walking the list every time you want to check the cause. It would

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

If you're talking about errgo, if all we care about is transition, but not what the actual types are, we could just record in the list when we mask the type. On May 27, 2014 8:48 PM, "Tim Penhey" wrote: > On 28/05/14 12:43, Nate Finch wrote: > > This sounds like one of those "if you have to ask t

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

On 28/05/14 12:43, Nate Finch wrote: > This sounds like one of those "if you have to ask this question, you're > doing something wrong". > > Can you give an example of where we need this? Sure... let's say we have a stack of errors, for simplicity of the argument lets say it is a slice of error i

Re: interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

This sounds like one of those "if you have to ask this question, you're doing something wrong". Can you give an example of where we need this? On May 27, 2014 8:24 PM, "Tim Penhey" wrote: > On 28/05/14 11:46, William Reade wrote: > > Re unsafe: where we can't check equality, we fall back on iden

interface identity (was Re: Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo))

On 28/05/14 11:46, William Reade wrote: > Re unsafe: where we can't check equality, we fall back on identity. We > know it's a hack; and if it's fundamentally broken, we'd like to know > why, so we can fix it. Please clarify your objections. I do have a question around this and it is one that I ha

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

Roger We have had many long discussions, and you have provided much valuable input: in particular, explaining to us that we were completely off-base re: the attempts to use a slice vs a linked list in the error stacks. And we did indeed agree to use errgo (as the only proposed implementation that

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

On 27 May 2014 04:02, Tim Penhey wrote: > On 23/05/14 02:47, roger peppe wrote: >> Any particular reason to wrap the errgo functions rather than using errgo >> directly? Personally, I see the role of the errors package to be about >> specific error classifications (something that errgo tries hard

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

On 27 May 2014 04:02, Tim Penhey wrote: > On 23/05/14 02:47, roger peppe wrote: >> Any particular reason to wrap the errgo functions rather than using errgo >> directly? Personally, I see the role of the errors package to be about >> specific error classifications (something that errgo tries hard

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

On 23/05/14 02:47, roger peppe wrote: > Any particular reason to wrap the errgo functions rather than using errgo > directly? Personally, I see the role of the errors package to be about > specific error classifications (something that errgo tries hard to be entirely > agnostic about), but errgo co

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

I agree with Roger, I don't think a wrapper around Errgo is the right way to go. If we don't like the way errgo behaves, we should change it. It's our package, let's have it work the way we want it to work. On Thu, May 22, 2014 at 10:47 AM, roger peppe wrote: > On 14 May 2014 10:24, Tim Penhey

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

On 14 May 2014 10:24, Tim Penhey wrote: > Hi all, > > I took it upon myself to get Rog's errgo library used inside juju-core. Thanks for doing this. > Dimiter recently did a hunk of work in the juju-core/errors package to > have functions to add context to some core error types while keeping > t

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

On Wed, May 14, 2014 at 8:12 AM, John Meinel wrote: > I'd like gccgo to pass reliably, but I think it falls under a CI test rather > than a pre-commit test. (Because otherwise it roughly doubles the time it > takes to know whether your patch will land.) I agree. We can setup gccgo-based test runs

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

I'd like gccgo to pass reliably, but I think it falls under a CI test rather than a pre-commit test. (Because otherwise it roughly doubles the time it takes to know whether your patch will land.) I don't have specific feedback on the behavior differences, but the changes seem sane to me. An errors

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

Hi all, I took it upon myself to get Rog's errgo library used inside juju-core. Dimiter recently did a hunk of work in the juju-core/errors package to have functions to add context to some core error types while keeping their type. What I did was to move this errors package out of juju-core and