Handle FreeDB server errors gracefully

[anarcat]

In my repeated tests, I ended up upsetting freedb.org, which started
issuing 502 errors. Those errors are not correctly caught by the
program which just crashes with a backtrace. Instead, we handle those
like any other API error, which can already be generated by
perform_lookup (but not handled).

The visible result for the user is that the CD is simply not found on
FreeDB, an acceptable compromise, in my opinion.

Closes: #206

[anarcat]

note that #206 was closed, but should be reopened before this is merged of course. :)

[JoeLametta]

Thanks for reporting this issue. I've reopened #206.

Shouldn't we just handle the exception in program.py without adding additional code to freedb.py? (the perform_lookup function in whipper's freedb.py is intentionally almost identical to the one found in python-audio-tools).

[anarcat]

Shouldn't we just handle the exception in program.py without adding additional code to freedb.py? (the perform_lookup function in whipper's freedb.py is intentionally almost identical to the one found in python-audio-tools).

The reason I did it this way was to catch the ValueError that could occur elsewhere in the freedb.py code. But it's true we could just catch URLError there as well. The problem then is we depend upon freedb-specific code: if they decide to switch to (say) requests to do network requests, our error-handling goes out the window. Plus it means we now depend on urllib in program.py, which is not currently present.

I was trying to keep things separate...

[JoeLametta]

The problem then is we depend upon freedb-specific code: if they decide to switch to (say) requests to do network requests, our error-handling goes out the window.

That's true, although we're not not relying on a blindly imported freedb module (the code is already quite customised, just see fdeeed9). Almost 3 years have passed since the last update to that file in the upstream repository.
Anyway I'm not opposing to the way you've implemented the fix, just trying to clarify the situation. I'll wait for your reply then will probably proceed to merge this pull request as is right now. 😉

[anarcat]

On 2018-10-06 09:53:24, JoeLametta wrote: > The problem then is we depend upon freedb-specific code: if they decide to switch to (say) requests to do network requests, our error-handling goes out the window. That's true, although we're not not relying on a blindly imported freedb module (the code is already quite customised, just see fdeeed9). Almost 3 years have passed since the last update to that file in the upstream repository. Anyway I'm not opposing to the way you've implemented the fix, just trying to clarify the situation. I'll wait for your reply then will probably proceed to merge this pull request as is right now. 😉

I don't really care either way... I just scratched an itch. Besides, all this would ideally go away and be abstracted in an external libdiscid right?

[JoeLametta]

Besides, all this would ideally go away and be abstracted in an external libdiscid right?

Don't know: it seems libdiscid only handles the computation of the IDs not the actual network communications with FreeDB or MusicBrainz (in whipper the former it's handled by the customisedfreedb.py, the latter by python-musicbrainzngs).