errors returned are gRPC errors

[mcarmonaa]

Errors returned by the client are all gRPC errors, so you can't distinguish for example if that error is an driver.ErrPartialParse error.

[smola]

@dennwc Any progress here? This limits our ability to decide a sane logging policy on gitbase.

[dennwc]

First, please switch to v3 branch. I will update it to support all specific errors returned by parsing code.

[bzz]

@mcarmonaa indeed, that was the case with old protocol. I belive there are no plans right now for changing it in v2.

But did you try latest https://gopkg.in/bblfsh/client-go.v3 ?

The protocol has been changed (see the DesignDoc for summary of the changes, including error handling), so a new version follows gRPC guldelines on error handling and error field of the response is reserved only for parsing issues.

[smacker]

bblfsh/web use-case:

resp, lang, err := cli.NewParseRequest()...UAST()

it looks like the error can be one of:

• network error
• any kind of internal grpc error
• driver error (can’t parse source code)
• bblfsh error (can’t create tree from the response)
• ???

We need to show driver error to the user but hide anything else with friendly message Unexpected error contacting babelfish server. Please, try again. (because it’s internal error and the user can’t fix it by providing different source code / language)

please correct me if my assumptions about errors are wrong or if there are any other errors that make sense to handle differently.