New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to customize errors response structure. #1321

Merged
merged 1 commit into from Aug 3, 2017

Conversation

Projects
None yet
3 participants
@brycereitano
Copy link
Contributor

brycereitano commented Jul 27, 2017

This provides the interface for merging custom error response structs.

Tests and documentation to come after review of approach.

@brycereitano brycereitano changed the title Initial mergable error commit. Add ability to customize errors response structure. Jul 27, 2017

@raphael
Copy link
Member

raphael left a comment

Looks great, thanks for doing this! I left a few nitpicks in the review.

error.go Outdated
@@ -265,6 +299,14 @@ func (e *ErrorResponse) Token() string { return e.ID }
// Merge returns the updated error. This is useful in case the error was initially nil in
// which case other is returned.
func MergeErrors(err, other error) error {
// If either err is mergable, merge them.

This comment has been minimized.

@raphael

raphael Jul 27, 2017

Member

This should probably be moved after the nil tests below

This comment has been minimized.

@brycereitano

brycereitano Jul 27, 2017

Contributor

Fair enough, the applications customized error handling should know how to handle a goa.ErrorResponse either way.

This comment has been minimized.

@brycereitano

brycereitano Jul 27, 2017

Contributor

Oh actually, there is an issue with that. That may turn a custom mergeable error into a *goa.ErrorResponse, stringifying the result into Detail.

This comment has been minimized.

@brycereitano

brycereitano Jul 27, 2017

Contributor

Maybe it would be better if ErrorResponse didn't implement ServiceMergableError. Removes the possibility of the old merging logic of being used when the ServiceMergableError should be.

This comment has been minimized.

@raphael

raphael Jul 27, 2017

Member

that makes sense to me, good catch!

error.go Outdated
}
return e
}

// MergeErrors updates an error by merging another into it. It first converts other into a

This comment has been minimized.

@raphael

raphael Jul 27, 2017

Member

This comment should be moved to the ErrorResponse.Merge method since the logic may now be different. The new comment should explain that the algo first checks whether err is mergeable and is so merges o into it then whether o is mergeable and finally creates a mergeable error with status code 500 if none is.

error.go Outdated
// ServiceMergeableError extends from the ServiceError interface.
ServiceError

// Merge will handle the logic of merging two errors together.

This comment has been minimized.

@raphael

raphael Jul 27, 2017

Member

will handle -> handles

@brycereitano

This comment has been minimized.

Copy link
Contributor

brycereitano commented Jul 27, 2017

@raphael Updated so that ErrorResponse doesn't implement ServiceMergableError. As it can cause the old merging logic to be called if err happens to a goa.ErrorResponse.

@brycereitano brycereitano force-pushed the brycereitano:enhancement/custom_mergable_errors branch from daca8ef to 4fa0767 Jul 28, 2017

error.go Outdated
@@ -254,6 +264,8 @@ func (e *ErrorResponse) Token() string { return e.ID }
// ServiceError if not already one - producing an internal error in that case. The merge algorithm
// is:
//
// * If any of e or other implements ServiceMergableError, it is handled by it's Merge method.

This comment has been minimized.

@seubert

This comment has been minimized.

@brycereitano

brycereitano Jul 28, 2017

Contributor

Nice catch, I'll get it updated.

@brycereitano

This comment has been minimized.

Copy link
Contributor

brycereitano commented Jul 28, 2017

Once this is merged, this should close #1173.

@raphael
Copy link
Member

raphael left a comment

Thank you for doing this, looks great! I left a couple of comments in the code review.

@@ -300,24 +310,22 @@ var _ = Describe("Merge", func() {
})
})

Context("with a nil argument", func() {
const code = "foo"
Context("with a nil target", func() {

This comment has been minimized.

@raphael

raphael Jul 29, 2017

Member

nitpick: the test is calling MergeErrors so really it's still an argument and not a target?

This comment has been minimized.

@brycereitano

brycereitano Jul 30, 2017

Contributor

The other tests used a similar terminology. However, I think target is fine, as it's the error that is modified.

})
})

Context("with MergableError", func() {

This comment has been minimized.

@raphael

raphael Jul 29, 2017

Member

would be good to also have a test where the first error is NOT a mergeable error but the second one is that validates the second error Merge method is called.

@brycereitano brycereitano force-pushed the brycereitano:enhancement/custom_mergable_errors branch from 4fa0767 to c585bdf Jul 30, 2017

@raphael raphael merged commit 4f4b96b into goadesign:v1 Aug 3, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@raphael

This comment has been minimized.

Copy link
Member

raphael commented Aug 3, 2017

Looks great - thank you! Do you think you could also send a PR against master? thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment