Error Handling and Format Cleanup

[Myoldmopar]

I'll start by saying I'm open to redoing any/all of this if you prefer a different path forward. But here's a starting point :)

Changes

• Addressing Error Handling
• Format Cleanup

Error Handling

• Fixes Fails in snap-installed Pycharm #84
• The core issue that started this was that if you execute this code from within a sandboxed environment, such as a snap installed (and confined) app, it is not allowed to do the right method calls across dbus. There's nothing really to "fix" except to alert the user about the issue so they can work around it. As of right now it would either fail with a random traceback, or say "Spotify is off"
• To address these, several things were done, including
  • adding a new custom Exception class for "known" exceptions
  • reworking exception handling to let them bubble up to the main() interface and exit properly
  • catching specific error conditions in the worker functions and converting them into the new custom exception class
  • modifying the __main__ utility script to return the exit code from the underlying main() function so that the command line interface will actually return the meaningful condition.

Format Cleanup

Before pushing the code, I ran the format checker. It reported tons of issues, but was returning 0. This is because it was just calling os.system and ignoring the error code. I modified the code to actually catch a format problem and let the checker fail. And then went through and cleaned up the format issues so the checker passes again.

I made several lines shorter to comply with the default line length restriction. In my personal opinion, 80 characters is a little restrictive, so if you'd prefer to make that like 100 or 120, I would be happy to adjust the checker and revert some of my line changes.

I'll document the changes in more detail in a code review in just a moment once the PR is open.

[Myoldmopar]

Alright, code walk-through completed. Let me know if you have any questions.

[pwittchen]

Thanks for the PR! I added just one comment regarding formatting. Regardless of this, the PR brings a lot of improvements. Moreover, you need to resolve conflicts with your previous changes.

[pwittchen]

Merge conflicts need to be resolved and one line needs to be re-formatted.

[Myoldmopar]

Conflict resolved and it should be clean. I'm still open to tweaking things if you'd like more changes before merge.

[Myoldmopar]

I think you are saying you'd like it kept in one long line rather than broken up. That is fine, but that would require telling pycodestyle to allow longer lines.

For now I will leave this line wrapped so that the format-checker passes. If you want me to adjust the rules on the format checker so that longer lines are OK, I'll do that.

[Myoldmopar]

OK, so with that everything seems functionally happy.

I see the merge is blocked because the branch contains a merge commit. I know different people like their branches cleaned up / squashed / rebased in different ways, so please advise how you'd like me to clean this up so it's ready for merge.

And finally, if you'd like me to loosen up the line length restriction I can do that (it's max of 79 characters when you use default). If that is loosened up, some of the line-wrapping can be reverted back to single lines.

And I appreciate you letting me contribute here. I love contributing to random projects, and this is especially useful for me.