Consider more appropriate error classes for networking or gateway failures

[jasonwebster]

One specific example that I ran into recently was dealing with bunk responses from Paypal when verifying an IPN signature. The code in

offsite_payments/lib/offsite_payments/integrations/paypal.rb

Line 302 in 62a1f83

raise StandardError.new("Faulty paypal result: #{response}") unless ["VERIFIED", "INVALID"].include?(response)

simply raises a StandardError, which makes it somewhat fragile to trap and deal with appropriately, as I had to rely on message substring matching to catch that specific one. However, this issue is wider spread than just the Paypal integration, as many of them raise StandardErrors for either malformed responses, networking failures or even input validation (where ArgumentError would be more appropriate).

Aside from some obvious places where we should raise ArgumentError instead of StandardError (

offsite_payments/lib/offsite_payments/integrations/paypal.rb

Line 20 in 33cb50e

raise StandardError, "Integration mode set to an invalid value: #{mode}"

for example), one option would be a base IntegrationError < StandardError, which we could subclass within each integration's namespace and be able to rescue specifically from as necessary. However, there might be some benefit in being able to distinguish between logic errors and network failures.