-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Display CLI usage on user error #819
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #819 +/- ##
===========================================
- Coverage 59.57% 59.56% -0.02%
===========================================
Files 155 155
Lines 17271 17275 +4
===========================================
Hits 10290 10290
- Misses 6051 6055 +4
Partials 930 930
|
Benchmark ResultsSummary
✅ See Better Results...
❌ See Worse Results...
✨ See Unchanged Results...
🐋 See Full Results...
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some thoughts
cli/cli.go
Outdated
for _, cobraError := range cobraErrors { | ||
if strings.HasPrefix(err.Error(), cobraError) { | ||
if usageErr := rootCmd.Usage(); usageErr != nil { | ||
log.FeedbackFatalE(ctx, "error displaying usage help", usageErr) | ||
} | ||
} | ||
} | ||
log.FeedbackErrorE(ctx, "DefraDB error", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: I'm not a fan of "DefraDB error" as a prefix here.
Additionally, there should be a difference between execution error and usage error. At the moment, it feels centered around usage error.
If it is a usage error, the prefix should indicate so, and should be logged before the Usage Help.
The original line log.FeedbackError(ctx, fmt.Sprintf("%s", err))
is prob helpful, maybe with slight modification for the execution error. It lets the error stand on its own.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback.
FeedbackErrorE
is used to support the inclusion of stacktrace if that's desired, and it requires a prefix, and includes the error message (and stacktrace) as KVs. It could be updated if the internal errors pkg would allow access to the stacktrace.
I've updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why you say it requires a prefix. Do you equate the message param to a prefix? Also, why would you want to have access to the stacktrace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By prefix I meant message param, yes.
For consistency, as the rest of logging gives stacktraces on demand. A user might want to obtain stacktraces from the top-level returned error too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be done already. Just use:
fmt.Printf("%+v", err)
to get the stacktrace
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the info Fred. i knew about it but had forgotten
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated with Fred's feedback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
cli/cli.go
Outdated
if cfg.Log.Stacktrace { | ||
log.FeedbackError(ctx, fmt.Sprintf("%+v", err)) | ||
} else { | ||
log.FeedbackError(ctx, err.Error()) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: I'm not sure I understand why you are doing this. Why not keep a message string and let the logger handle displaying the error's stacktrace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
two currently conflicting goals:
- have consistent log output formats across defradb
- pleasant human experience using the program
for this PR it's best to prioritize have consistent log output formats across defradb, so reverted back.
in upcoming CLI work i'll resolve these currently conflicting goals ...
053c9f7
to
3c7e4e2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Relevant issue(s)
Resolves #669
Description
Displays usage text on 'user error' (failure to summon a valid command).
Given current release timeline, I suggest tests for this are to be included in next release.
Limitations:
DefraDB error
in addition of the error itself because internal logger interface doesn't allow to display directly an error and its stacktrace (when we configured to display stacktrace).I thought that was the least worse way to achieve this UX feature given the options I considered (listed in the issue).
Tasks
How has this been tested?
Manual
Specify the platform(s) on which this was tested: