[ENH/TST] Raise Consistent Error Types

[loganthomas]

Brief Description

I would like to propose a consistent framework for raising errors within pyjanitor.

• There is a JanitorError class that is being used by some modules to raise errors
• There are also other places in the codebase that uses ValueError, TypeError, KeyError, etc.
• Should we be consistent with raising errors across the board, or are the ValueError, TypeError, KeyError, etc. being explicitly used on purpose?

Example API

• janitor/io.py uses JanitorError and ValueError

• janitor/utils.py uses TypeError, JanitorError, and ValueError

• janitor/finance.py uses ValueError and ConnectionError

• janitor/functions.py uses TypeError, ValueError, JanitorError, IndexError, NameError, KeyError

• Some of these may be intentional and make sense. For example, in janitor/finance.py a ConnectionError is raised as a result of using requests and not getting a 200 status code. This makes sense.

• Are the other error types as intentional as the ConnectionError described above?

• Just thinking that being consistent with using JanitorError may help users know when an error is coming from pyjanitor vs. another source. If we were to always return a JanitorError, could that help with debugging? Just a thought...

[samukweku]

I have been thinking about this, and I may have a look at some of my previous contributions and see if I can just replace them with JanitorError and other functions from the utils section. It certainly would be consistent, not so sure about debugging though.

[ericmjl]

@samukweku and @loganthomas I think we've used each kind of error in an intentional fashion.

A good reference for which one we use in which case is the official docs.