CLN: Remove unused Exceptions
There are at least 3 `Exception`s that are _never_ raised anywhere, so they can be removed without issue. (There are other exceptions that probably should be removed or refactored, but this is just a basic commit to make sure that these don't get used going forward.)

CLN: Remove 'DateConversionError' that is never raised anywhere

CLN: Remove TimeSeriesError that was never used

CLN: Remove unused 'PanelError'

Is it good practise to ever be subclassing the Exception class (rather than using a more specific Error)? E.g these, PandasError, etc.
 well, the goal is to use as few custom Exceptions as possible and
eventually change all exceptions to either subclass from PandasError or use
builtin Exceptions. That said, both `core/index.py` and `core/groupby.py`
use the custom exceptions internally, so some them probably should stay in,
even if the user never sees them.

Do you mean subclass here or raise? Because definitely aiming to remove all
the usage of `raise Exception` within the code eventually.

On Sun, Jun 16, 2013 at 6:38 AM, Andy Hayden notifications@github.comwrote:

> Is it good practise to ever be subclassing the Exception class (rather
> than using a more specific Error)? E.g these, PandasError, etc.
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/pydata/pandas/pull/3921#issuecomment-19510634
> .
 Definitely agree about removing raise Exceptions. :)

I was just wondering if there was a valid purpose in PandasError type exceptions in the first place? (I'm not saying I have an opinion on it...)
 I'm definitely not an expert on the pandas code base, but my impression is
that part of the reason groupby can do all the magic that it does is
because it uses exceptions as message-passing mechanisms (which is legit -
it's a way to break out of deeply nested code, etc.). My feeling is that
anywhere you have some kind of issue that is both specific to Pandas and
probably needs to not bubble out to the user, it could be reasonable to
raise and then catch a PandasError, allowing other kinds of exceptions to
go through.

That said, this is a first step towards _not_ relying on custom exceptions:)

On Sun, Jun 16, 2013 at 9:09 AM, Andy Hayden notifications@github.comwrote:

> Definitely agree about removing raise Exceptions. :)
> 
> I was just wondering if there was a valid purpose in PandasError type
> exceptions in the first place? (I'm not saying I have an opinion on it...)
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/pydata/pandas/pull/3921#issuecomment-19512098
> .
 that's exactly right both in groupy and indexing

these are not _real_ exceptions and should not interact with user facing (or even test code)
 @jreback Ah, this makes sense.

The example I was thinking of was when Series or DataFrames is instantiated incorrectly (which does give a PandasError), which _is_ user facing... so the type of things should be tweaked to non-custom?
 can u put an example up?
 ```
In [2]: pd.DataFrame('b')
---------------------------------------------------------------------------
PandasError                               Traceback (most recent call last)
<ipython-input-2-b9c18eb37b5d> in <module>()
----> 1 pd.DataFrame('b')

/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pandas/core/frame.pyc in __init__(self, data, index, columns, dtype, copy)
    448                                          copy=False)
    449             else:
--> 450                 raise PandasError('DataFrame constructor not properly called!')
    451
    452         NDFrame.__init__(self, mgr)

PandasError: DataFrame constructor not properly called!
```
 what do u want to replace this with?
 Probably that particular one could be a TypeError? :s

_Just trying to recall why this came up... It was that I was surprised that `Series(2) == 2` (or any scalar), and this usage didn't seem documented (it had a test case and was exploited in exactly one other test case). Maybe I'll make pr to discuss._
 yeh series(2) == 2 should be deprecated anyhow
 Oh good, glad you agree, I'll put up a pr. My opinion:

```
isinstance(Thing(x), Thing)  = True  # always
```
 @jreback @hayd @cpcloud  hey, just a quick question - I have a bunch of pull requests up now, some of which definitely aren't ready to be merged, some of which definitely could be merged. Before I go down the rabbit hole with certain PRs (especially the broader one on fixing Exceptions and using numexpr), is there anything I need to do to get them to be accepted? I just want to make sure I'm not missing something here.
 i think all are merge-able except the ne and exceptions one and possibly groupby aggregate funcs (i haven't read through the thread or the issue)

makefile shortcuts pr is probably benign since only contributors will use them

i'll go thru and mark the ones i think are merge ready

crlf's not sure there, but probably benign

cc @y-p 
 @jtratner only thing is that u should probably rebase most of ur prs
 I would also say, if you think a pr is good to go, and should be merged, then @ someone / people and say something like "I think this good to merge...". Seems what most people do! :)
 @hayd thanks - that's helpful. I've never really contributed to a project
before, so I'm still learning the ropes. :)

On Sun, Jun 16, 2013 at 7:59 PM, Andy Hayden notifications@github.comwrote:

> I would also say, if you think a pr is good to go, and should be merged,
> then @ someone / people and say something like "I think this good to
> merge...". Seem what most people do! :)
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/pydata/pandas/pull/3921#issuecomment-19521527
> .
 @jtratner right there with u buddy, i've only been hacking on pandas for a little over a month
 `grin 'DateConversionError'` shows

```
./pandas/io/parsers.py:
   28 : class DateConversionError(Exception):
 1757 :     except DateConversionError:
```
 oh i c nevermind
 I've been using PyCharm for this...very convenient and makes it easier to
figure out where these are used, etc.

On Sun, Jun 16, 2013 at 9:22 PM, Phillip Cloud notifications@github.comwrote:

> oh i c nevermind
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/pydata/pandas/pull/3921#issuecomment-19522730
> .
 @cpcloud I think this is good to merge.
 good 2 go?
 I can rebase first if necessary...
 No need :)
