Skip to content
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

Jump to bottom

Improve reporting on user errors #3

Open
frosch123 opened this issue Apr 22, 2020 · 2 comments
Open

Improve reporting on user errors #3

frosch123 opened this issue Apr 22, 2020 · 2 comments
Labels
good first issue Good for newcomers

Comments

@frosch123
Copy link
Member

When the user specifies incorrect/insufficient options, the CLI usually prints a long backtrace.
Maybe add --verbose option to print backtraces, and hide them by default.

Examples:

When --api-url is wrong/missing:

  • about 60 lines of python backtrace
  • aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host api.bananas.openttd.org:443 ssl:default [Name or service not known]

When uploading zero files:
.env/bin/python -m bananas_cli --api-url https://api.bananas.staging.openttd.org upload --version "foobar"

  • 25 lines of python backtrace
  • File ".../bananas_cli/commands/upload.py", line 31, in upload
parts = files[0].split("/")[:-1]
IndexError: tuple index out of range
@frosch123 frosch123 added the good first issue Good for newcomers label Apr 22, 2020
erenes pushed a commit to erenes/bananas-frontend-cli that referenced this issue Apr 10, 2021
Fix OpenTTD#3: Show more meaningful errors to cli users
859c851
@erenes
Copy link

erenes commented Apr 10, 2021

I've fixed this specific issue in the commit mentioned above, but I based it on a branch already containing my PRs #20, #21 and #22.

There will be some merge conflicts if we merge them one by one, so before sending a PR for this, I wanted to check if it would be better to send a new PR that combines all the fixes in one PR, or would you rather merge the other PRs first and then have me rebase off that?

@TrueBrain
Copy link
Member

TrueBrain commented Apr 10, 2021 •
edited

What I commonly do, is make the PR with the others included, and stating that in the Pull Request (something like: include #.., #.., etc). That means for the reviewer it is clear in which order he should review the stuff, and makes sure you don't have to make your life very complicated :D

Also poke to reviewers to get a move on :P

@erenes erenes mentioned this issue Apr 10, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
good first issue Good for newcomers
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@TrueBrain @erenes @frosch123