Throw specific errors instead of generic 'Exception' would make for safer and nicer client implementations

[Marco Antonio]

Summary

Not throwing specific exception make clients error handling to be coupled with weak interfaces in the library. Throwing specific errors means exposing more explicit and stable interface for errors.

Example

In my implementation I had to look for a sub-string with the specific error message in the error to be able to know which type of error it is. In other words, an error from network, or proxy, or non listed ticker symbol all look the same from the outside of the library.

Currently my implementation is something like:

    try:
        hist = ticker.history(period='3mo', interval='1d', raise_errors=True)
    except Exception as ex: 
        if 'No data found, symbol may be delisted' in str(ex):
            flash('The provided ticker symbol was not found, perhaps you mispelled it?', 'error')
            return redirect('/')

Where I'd like to go like:

    try:
        hist = ticker.history(period='3mo', interval='1d', raise_errors=True)
    except YFinanceNotListedError as ex:
            flash('The provided ticker symbol was not found, perhaps you mispelled it?', 'error')
            return redirect('/')

The way it is today, if anyone unsuspectingly changes the error message, that would break all implementations relaying on that.

I think this person had the same issue I had #1918

(Thanks for the lib, BTW)

[ValueRaider]

#1918 was almost perfect, I just wanted a runnable code example of breakage to begin planning release - versioning etc.

[Marco Antonio]

I think it is possible to make it in a way that is fully backwards compatible. Would you please assign it to me? I could offer another PR based on #1918

[ValueRaider]

I don't assign tasks, just give @elibroftw a chance to be involved if they want.