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

Fixes some error handling when unexpected input is given #4

Merged
merged 3 commits into from
Feb 5, 2015
Merged

Fixes some error handling when unexpected input is given #4

merged 3 commits into from
Feb 5, 2015

Conversation

schwartzmx
Copy link
Contributor

The current stackit, throws some nasty stack trace if invalid input is given after searching for a question. See:

Press m for more, or a number to select: s
Traceback (most recent call last):
  File "/usr/local/bin/stackit", line 9, in <module>
    load_entry_point('stackit==0.1.2', 'console_scripts', 'stackit')()
  File "/Library/Python/2.7/site-packages/stackit/stackit_core.py", line 188, in main
    searchTerm(term, tags)
  File "/Library/Python/2.7/site-packages/stackit/stackit_core.py", line 76, in searchTerm
    focusQuestion(questionLogs, count)
  File "/Library/Python/2.7/site-packages/stackit/stackit_core.py", line 43, in focusQuestion
    if(0 < int(userInput) and int(userInput) <= count):
ValueError: invalid literal for int() with base 10: 's'

I altered some wording, and also added some error catching to make it not spit out the stack trace. Also added q option for quitting a search.

Comments or concerns let me know.

Thanks,

Phil

@lukasschwab
Copy link
Owner

Ayyy Phil

We dig it––thanks for catching the issue and implementing the "quit search" feature, which we've wanted to implement but haven't gotten around to doing.

We'll test your code and get back to you, hopefully later today!

Thanks for the pull request,
Lukas

printQuestion(questions[j], j+1)
continue #exit the inner while loop
except:
if (userInput != 'q'):
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The userInput == 'q' case is handled above, in line 44––is there a reason for this redundancy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you throw the exception after the check, it automatically propagates to the except: block. So when letting the user know what happened, you need to check if the exception occured because of q, if it didn't then let the user know why. If it did then just exit as normal.

@schwartzmx
Copy link
Contributor Author

I also added similar checking for branchInput looping, because the same error could occur. Also if a user found the answer after taking a closer look (i.e. by entering a question number), give them the option to quit right there, and not have to ctrl-c or hit x then q.

Also give a meaningful message on why nothing happens when an integer out of the range of (0 < int(userInput) and int(userInput) <= count) is entered... and then re-prompt.

Let me know if you have anymore concerns.

Thanks,

Phil

@lukasschwab lukasschwab merged commit a525436 into lukasschwab:master Feb 5, 2015
@lukasschwab
Copy link
Owner

@schwartzmx our first pull request is now merged!

For now, you will be listed in README.md as Phil, with a link to your Github profile––let me know if you want me to display any more//less information.

Thanks for working with us!

@schwartzmx
Copy link
Contributor Author

@lukasschwab No problem man, and what a great idea you all came up with. As I use it more and find other features that may be useful I won't hesitate to open another PR.

Edit: And thats fine for the README. Thanks

Cheers, have a good night.

Phil

@schwartzmx schwartzmx deleted the task/fix-error-handling branch February 5, 2015 05:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants