Open lukemarsden opened 8 years ago
So the better way to catch internal behaviour without:
... is to write the error to the context and let the library user inspect it with their own logging middleware. However, I want to understand (links to specific lines would be best):
http.Handler
to the library, and it calls that on error, else it's own default.I just ran into this problem, I think: I had this method signature:
func (c *WorkspaceResource) GetAllByPartialSlugOrName(r *http.Request, query string, reply *[]Workspace) error {
And merged and deployed it and couldn't figure out why rpc kept telling me "not found" for about two hours. I suspected some problem with the deployed binary, not that the code was there and being ignored. The fix is that query should be a *string, I think.
It would be nice if there were warnings or a debug mode that complained about methods that look like RPC calls but are off by a tiny bit, or the error was "found method with that name, but an incorrect signature" or something.
As a new user, it would be great to be able to "see what is going on inside Gorilla" during development so that I can debug my program, especially since some parts of Gorilla are "magic" (e.g. use reflection in
serviceMap.register
).Requirements:
https://github.com/gorilla/rpc/pull/45/files is an example of debugging one user (me) added in order to figure out what was going on. Note that the logging that was added is happening in non-error cases. For example in
rpc/map.go
in early exit cases of theregister
method.One suggestion in https://github.com/gorilla/rpc/pull/45#issuecomment-231968264 by @elithrar is to enrich the error messages bubbled up. However this only works if the developer is able to get the information they need by logging error cases. My experience with gorilla was that it didn't error enough. I was logging all my errors. But Gorilla silently sent 400s back to the client, without logging enough information to understand why it was sending a 400 back.
I agree that "allowing the application to decide what & when to log whilst still enabling debugging" is what we want here, but in its current form much of the gorilla code makes decisions silently and in a way that doesn't allow an application developer to introspect it at runtime without reading/editing/single-stepping through the library code.
Possible solutions:
Thoughts?
Thank you for building Gorilla, it's great!