Gremlin Server errors reported to the client aren't always telling. It typically returns the error message from an Exception (and tries to pull the "best" message by unwrapping the "cause" if present). That approach works for most cases but I've had the disprivilege of being on the receiving end of some of those errors in debugging when only the client side message was present and it's a mess trying to rectify that simple message with a server log somewhere. Another annoyance is when you get an empty exception message on the server - which in turn translates to an empty error message on the client.
I'm planning several changes which I think will be good: 1. Include "exceptions" and "stackTrace" in status attributes where "exceptions" will be a list representing the exception hierarchy and "stackTrace" will obviously be the remote stack trace encountered. These will be added to both the Gremlin Server protocol and the HTTP protocol 2. Deprecate the "Exception-Class" in the HTTP protocol which is now better served with "exceptions". "Exception-Class" doesn't match our naming scheme and only yields the top level exception which isn't always useful to solving the problem. 3. Alter the ResponseException in the java driver to expose the two new fields when a remote exception is raised. Not sure if we want to beef up the python driver's error handling - it looks like right now it just concats the status and message into a string output. Perhaps that's a separate issue - maybe Dave can offer some thoughts since he's most familiar with that code. Could this be handled any differently or can we do anything else to help make debugging server problems a little easier?
