when voting, add "user X is not a member of community Y" error about gov4git HOT 2 OPEN

@dworthen as I look at the code, I see that the code already produces an error amounting to "user X is not a member of community Y", specifically this one https://github.com/gov4git/gov4git/blob/v2/proto/ballot/ballotpolicies/sv/verify.go#L27

Was your issue simply that you couldn't parse it out when it's mixed in with the stack trace, or are you not able to observe this error at all?

Or, is your request to have an error message that literally spells out "user X is not a member of community Y". If this was your intention (I am guessing not), I want to point out that the errors returned from the backend should be viewed as an interface between the backend and the frontend — they are not generally targeted for the end-user to see. The key thing for us would be to have a backend/frontend contract that fixes the message format for this specific error, so that the frontend can always recognize it and present meaningful options to the user.

If you think that a text message is an awkward datamodel for communicating errors (e.g. some errors may want to communicate parameters), then I can produce structured errors which will appear in the cli result structure under the field "error" in the form of a JSON structure. Example:

{
   "status": "error",
   "msg": "voter is not in the community",
   "error": {
      "voter_not_a_member": true,
      "voter_repo": "https://github.com/xxx/gov4git-identity-public"
   }
}

Let me know what you think.

from gov4git.

I think the general goal is to have a general format for responses that incorporates the possibility of errors in a way that is easy to parse. Stack traces and plain strings returned from the CLI are hard and brittle to parse. A string without a label or context is hard to know if it is an error or the expected response. Stack traces are just problematic to parse programmatically and reliably and there can be multiple stack traces with varying lengths or thrown from different spots that essentially mean the same thing such as user not found. In Gov4Git's case a lot of stack traces end with "File not found" which can mean a whole variety of things.

I am fine with the msg field for reporting errors. I am not sure about the error object. I am not a fan of dictionaries with unknown keys and would prefer typed objects of known keys. That makes it easier to parse and understand. In #166 I also suggested using something like a status field much like HTTP status codes. Something that can either be a field enum or number. Something that gives us fine grain labeling and classification of errors without having to rely on the error message which may change overtime or be brittle to parse and rely on.

from gov4git.