Open vsoch opened 5 months ago
I want to ping again on this issue (because I'm hitting it again). Even when I call cli.GetErrMsg()
the error message isn't great to tell me what is wrong:
I suspect it's the same or a similar issue as before (I'm converting JGF v2 back to v1 for flux) but probably if we give this API a look a more meaningful message to the developer user would be really helpful.
lol my matcher is localhost... HOLD THE PHONE! :phone:
:laughing:
Note to self: when copy pasting a string flag, make sure to change the default from the previous string flag...
Why yes, operator, I know my neurons are going to sleep and so should I. What's that? This banana and my hand are not telephones? Says who!
slams telephone
ouch. :face_with_head_bandage:
Yes, banana phone :banana: I do believe it is time we went to sleep. Why am I talking to you? Why are you talking to me, you're a banana?
narrator voice @vsoch does not talk to inanimate objects, mostly herself, and likes making very bad jokes.
When our current PRs are merged, I'd like to do a PR to make changes similar to here. Basically, when we are developing with the flux go bindings, an error message might look like the following:
We get a generic message "error creating context" and the return code, which isn't helpful. The developer here could make a call to
cli.GetErrMsg()
, but the issue is that if the developer is, for example, not touching the code but instead working on some json graph, they will have no clue what is wrong. When I add a simple tweak to my test branch to retrieve the message (given nonzero) I am passed forward the message:Ah yes, my malformed metadata! Of course! So when https://github.com/flux-framework/flux-sched/pull/1120 is merged I'd like to follow up with a PR to do this small change, and I'd also propose renaming the
GetErrMsg()
to be fully written out (mostly for consistency in our naming) and I'll make sure to fix all the places in other projects that function is used.