Comments (15)
from errors.
Yeah, what you've described is the option I've settled for. My only qualm with it is that, in the non-contrived version of this scenario, I actually have multiple "things" that may error. So, I feel like it would be nice to assert that the correct error was raised, rather than just an error.
That said, if I were truly blackbox testing myFunc
, I wouldn't have any reason to expect a specific error¹. And, actually, checking error.Cause(...)
would probably be more appropriate given that I'm passing in the helper that generates the "causal" error.
¹ Unless I were doing TDD to prescribe the errors that my function returns.
--
Edit: I've since decided that this is the wrong approach.
From the standpoint of my test, all I should know about the function-under-test is:
- the stub I've provided will return a specific error
- my function should return a new error whose
Cause
is that stub-error
If I have multiple "things" that are all calling the same function on the stub, I might need to build a more advanced stub that is capable of handling many input values and only erroring for the ones that match the scenario I'm testing. Anything more than that, and I'm creeping into whitebox testing.
Also, the function under test should be free to modify its error messages without breaking the test.
from errors.
Can I suggest an alternative? Have your errors implement a specific interface, and then when you respond to the client check if the error satisfies that interface and respond appropriately.
Here's a short example of what I mean: https://play.golang.org/p/xpl-71EKbj
And one a bit longer checking for different errors. https://gist.github.com/groob/ff49f470eeb389c7aa237e667beab326
from errors.
Maybe errors.Wrap
is not what you want.
It feels like you are trying to create a side channel to send extra data related to the path the code took to the site the error was generated. You may be better served by writing your own error type.
See also #34
from errors.
I found myself wanting this as well. In my case I was wrapping my errors with an additional message. My http service has a single point of logging errors, and to avoid sending too much information (some that may be private) to the http client, I'd like to just extract the friendly the message as well, but log the stack trace.
So I can do it using my own event type, but then I'm supply 2 messages which is redundant. Of course I could be doing it all wrong as well, but in my case a Wrap without requiring a message could be an alternative.
from errors.
A wrap without a message is called WithStack. Is that useful for your use case?
from errors.
A wrap without a message is called WithStack. Is that useful for your use case?
Yes, sorry for the noise, I should have dug a bit deeper first. Just tried this out for my use case and it gives me exactly what I need. Thanks.
from errors.
I've been in the same situation as @gudmundur. I love this package, I'm using it in all my project. So first, thank you.
My use case is the following:
var ErrNotFound = errors.New("")
func fn(f string) (error) {
return errors.Wrapf(ErrNotFound, "The file %s has not been found", f)
}
func main() {
err := fn("/nonexistant/blah")
if err != nil {
log.Fatal(err.Error())
}
}
I'm using ErrNotFound
just to contextualize the error, meaning I can later do error.Cause()
to get the underlying error and match it to ErrNotFound
variable.
What I found too bad is that doing var ErrNotFound error
which will set it to nil
, Wrap()
-- or others -- will return nil
causing the error to never enter the condition.
What about treating Wrap(nil, "message").Error()
like if "message"
was the latest message's hence won't have the last :
?
I can try to come up with a PR if you think that's a good idea.
from errors.
from errors.
Hi @davecheney thank you for answering this fast!
Yes you are right, that's what I ended up using in most cases. But I am still leaning towards treating the root cause as a variable that I could compare to something without having to declare a new struct every time I have a new "simple" error.
I really like for example the "io"
package where you can simply compare the error interface against the variables that are declared in the package. But I loose the "printf" ability though and was trying to find a compromise since I didn't want to return the message from the underlying error but from where it came last.
I'm also sure that I'm doing things wrong, I'll try to look at some code to really understand how to do errors. I actually discover your package through your blog entry: https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully which totally helped me a lot already.
from errors.
from errors.
Ok I'll think about it more and give it a try, maybe with a new approach. Thank you so much for taking the time.
from errors.
Yes, I have had a few people tell me, “but the standard library does XY” and I’m like, well… it was written in an earlier time, and views have changed about the best way to do XY now…
Of course, I still think the “oob” conditions (io.EOF) being applied in the error namespace is the biggest example of this, with option applications second.
from errors.
Jumping in here because I haven't seen anyone mention my use-case.
I would find being able to access the message useful for testing. i.e:
func myFunc(thing3Helper helper) (error) {
doThing1()
doThing2()
err := doThing3(thing3Helper)
if err != nil {
return errors.Wrap(err, "Failed to do thing 3")
}
}
func TestReturnsCorrectErrorIfThing3Fails() {
helper := helperThatFails{}
err := myFunc(helper)
assert.Equal(err.Message(), "Failed to do thing 3")
}
It would be nice to be able to treat doThing3
as a black box and not need to know what its errors look like.
Would this be a valid case, or am I misusing this library?
from errors.
I think in this case you are attempting to fit a square peg in a round hole.
If you wish to treat doThing3
as a black box, then you should be testing doThing3
directly, rather than in the composed myFunc
.
Testing that myFunc
returns an error in the case of doThing3
returning an error need only be tested insofar as myFunc
will return a non-nil error when doThing3
would return an error. The form of the error itself is otherwise irrelevant. (Unless you have documented it to be relevant.)
from errors.
Related Issues (20)
- Proposal: add errors.Is and errors.As
- RFC: Allow custom StackTraces
- func Is() does not works with errors.Wrap or errors.Wrapf HOT 3
- Cause() behavior has changed HOT 11
- respect -trimpath build flag HOT 3
- Unwrap doesn't return the base error HOT 7
- Questions about extending annotations HOT 5
- undefined errors.Wrap HOT 2
- How to change format return wrapped error message HOT 2
- Stacktrace don't print all stack HOT 6
- errors.Wrap() created bugs in our codebase. HOT 3
- StackTrace.Format with "%+v" includes a leading newline HOT 1
- A new error caused by another error HOT 7
- Demo
- Change Wrap() to return an error even if we provide nil HOT 3
- return *stack instead of stack HOT 2
- Wrap() duplicates call stack HOT 6
- Elegant way to check error is wrapped HOT 4
- `Errorf` should be able to wrap errors HOT 4
- Package errors looking for new maintainers HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from errors.