Skip to content

CLN: Replace bare exceptions with more descriptive ones #3924

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

Closed
wants to merge 15 commits into from

Conversation

jtratner
Copy link
Contributor

This takes care of the low-hanging fruit (really obvious Exception changes), there are still a bunch more to change, but I thought I would split it up into parts and deal with external exceptions before messing with anything that might potentially be raised internally. [I rebased this slightly to remove a few comments - but it did pass previously so it should be fine]

@jreback
Copy link
Contributor

jreback commented Jun 16, 2013

here's the hard part
need to also change the corresponding test (if there is one)
to the new exception

you can easily do this by temporarily not raising (comment it out)
then the test should break and u can fix it

if it doesn't break then we r not testing it

tests are almost certainly for bare Exception

@jtratner
Copy link
Contributor Author

@jreback okay, will do :)

jtratner added 15 commits June 18, 2013 01:40
Replace with more descriptive exceptions
Replace with more descriptive exceptions

CLN: SparsePanel: replace bare exceptions

CLN: SparseFrame: change bare exceptions

CLN: SparseSeries: change bare exceptions

CLN: SparseArray: change bare exceptions
Replaces bare exceptions with more descriptive ones.
CLN: tseries/frequencies: replace bare exceptions

CLN: tseries/index: replace bare exceptions (mostly tz-aware + tz-naive
TypeError stuff)

CLN: tseries/offsets: replace bare exceptions

CLN: tseries/tools: replace bare exceptions
@jtratner
Copy link
Contributor Author

@jreback I've been writing out test cases for all of this, but it's involving some minor changes all around too. Would it be okay if I split this up into multiple PRs? (for example, right now I have test cases edited for stats, tools, tseries and sparse, could I submit those as PR and then continue working?)

@jtratner
Copy link
Contributor Author

I'm just concerned that it's going to get more and more difficult to merge the more files that are changed.

@jreback
Copy link
Contributor

jreback commented Jun 19, 2013

yes smaller PRs prob easier in this case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants