Enable visibility during development

[lukemarsden]

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:

• Should not noticeably slow down production code
• Should be able to see which RPC methods are exposed when services are registered (currently cases "method was not registered" and "client sent bad data" are indistinguishable, both give 400s)
• Should be able to see inputs to the system (e.g. incoming request bodies)

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 the register method.

One suggestion in #45 (comment) 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:

• A compile-time debug flag to turn on verbose logging of every important decision gorilla makes (perhaps parameterizable by a logger, to avoid using global logger?)
• An optional channel on which such decisions could get sent (not all useful debugging information coincides with an error object being created).

Thoughts?

Thank you for building Gorilla, it's great!

[elithrar]

So the better way to catch internal behaviour without:

• Logging in the library (ever), or;
• Returning errors;

... 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):

• Where you want to see information
• Whether we can bubble this up, if not being done so already
• Whether we can provide a way to plug into the error handler - e.g. you provide your own http.Handler to the library, and it calls that on error, else it's own default.

[kevinburke]

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.