Allow different policies for exception managment

This is my suggestion to be able to call Stripe.ipn capturing exceptions, so I can call it in a loop contest. If this is accepted here, then this could be done in the Stripe IPN API call.

That would allow automated retries of missed Stripe events.

mentioned in commit capo/stripe@fa17e6f0

This seems like a reasonable use case. Anytime we call exit() it makes the code far less useful.

I imagine the 400 error is intended for Stripe to let Stripe know that the event was not properly received. Is it wish full thinking to call http_response_code(400); and throw the exception so everyone is happy and we don't have to add that switch?

Let me see if I understood. Your suggestion is to just replace the exit statement:

  http_response_code(400);
  exit(1);

with a throw?

  http_response_code(400);
  throw new Exception($message);

I suggested the setExceptionMode approach as I thought this way I wasn't interfering with what happens during IPN calls. But if it's legit to throw instead of exit also for IPN usage, then let me know and I'll simplify my pull request removing the setExceptionMode method.

I think we should hear from @mattwire - I'm not sure if that solution would work or not.

But now I'm realizing that you seem to have opened this issue against a fork of the mjwshared repo - I think you'll want to open this issue on https://lab.civicrm.org/extensions/mjwshared where it will get Matt's attention.

Wtf! You're right! My apologies both to the owner (@scardinius) and to @mattwire. I'll close this one and send a pull requesto to the right repo. Thanks @jamie for the third eye!

closed

mentioned in merge request extensions/mjwshared!5 (closed)