CLN: remove bare excepts
 - [x] closes #14554 
 - [ ] tests added / passed: updated test_indexing.py
 - [x] passes ``git diff upstream/master | flake8 --diff``
 - [x] whatsnew entry

Errors in indexing no longer forced into KeyError
## [Current coverage](https://codecov.io/gh/pandas-dev/pandas/pull/14700?src=pr) is 84.55% (diff: 0.00%)
> Merging [#14700](https://codecov.io/gh/pandas-dev/pandas/pull/14700?src=pr) into [master](https://codecov.io/gh/pandas-dev/pandas/branch/master?src=pr) will not change coverage

```diff
@@             master     #14700   diff @@
==========================================
  Files           144        144          
  Lines         51043      51043          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits          43160      43160          
  Misses         7883       7883          
  Partials          0          0          
```

> Powered by [Codecov](https://codecov.io?src=pr). Last update [73bc6cf...6c4b4cd](https://codecov.io/gh/pandas-dev/pandas/compare/73bc6cfb35a886b18955b1f0a07f7647f1f1d409...6c4b4cddff6a60f14b0214e35f9e791ea40559e7?src=pr) needs the test from the issue  I'm struggling with the intent of what's going on then.   

Indexing errors and key errors should be converted to key error,  everything else (like the bug reports recursion error) shouldbubble up?  Thanks for the understanding,   This is one of my first non doc PRs.  > Indexing errors and key errors should be converted to key error, everything else (like the bug reports recursion error) shouldbubble up? Thanks for the understanding, This is one of my first non doc PRs.

no they should be converted to the ``_exception``. you can try just catching ``IndexError/TypeError`` where where the bare exceptions are now.

Its very important that the exceptions that are related to indexing are consistent (think from a user perspective). and so we don't/can't change them. However we may have an implementation that actually does positional type things (e.g. ``.take``), which may raise an error for something not found, but (in this case) are doing label indexing so a ``KeyError`` is correct, but the same code block may *also* handle positional indexing (the subclasses define _exception), so the ``_exception`` is then ``IndexError`` (again for consistency). @jreback What's the best course of action here? Some of the builds are failing, but for conflicting reasons. 3.4 is blowing the stack, 3.5 is failing because it because the recursion limit is being set to low.  I've reached an impasse in googling.  Something doesn't smell right in artificially setting the `setrecursionlimit`, but I can't think of another way to ensure the stack doesn't actually overflow before the exception it thrown?   @jreback Updated and squashed. can you rebase and push again. like to see this all green. My git-foo was all jacked up. I have no idea what happened. Please let me know if current push works. @clham Can you push again? For some reason, the tests didn't run Done.  Still seems not to be triggering.  Should I try adding a commit?
 Can you fix the merge conflict and in the whatsnew file, and push that? made a change and repushed:  still doesn't appear to be getting pulled into Travis or AppVeyor.  Conflict was also resolved.  it is only a few small changes.  does it make sens to nuke the branch and submit a fresh PR? resubmitted as #14912 .  Just starting over  to make the pain stop.  