Re: Error handling in a module

So it is better that my module doesn't stop the website from working, it allows the site creator to check for errors and get an idea of what the error is

Yes Bod, you're on the right track here. While unit tests help the developer create better quality modules, that is a different problem to remotely supporting a software product!

As mentioned in passing here, effectively supporting a complex product remotely isn't easy. Unit tests are not enough. You'll need to provide some sort of logging and notification mechanism, without degrading user experience. (For a gentle introduction to Log::Log4perl, see Logging with Log4perl (perlmaven)).

Unfortunately, I am not qualified to comment on how best to support and troubleshoot a Stripe Payment Gateway. Have you researched how others do it?

Comment on Re: Error handling in a module

Replies are listed 'Best First'.
Re^2: Error handling in a module by Bod (Parson) on Feb 27, 2023 at 00:38 UTC
Unfortunately, I am not qualified to comment on how best to support and troubleshoot a Stripe Payment Gateway The Stripe Gateway isn't really a problem - it can only do three things. 2 are normal behaviour and one is an error which I handle in the module. It's the way my module handles errors that I am concerned with and I feel I am doing it a sensible way. I was more wanting to check that there wasn't a "better" way that I had overlooked and I am now satisfied that the way I've approached it is sensible and useful to anyone losing my module. The 'errors' are more 'failed validation' of user input than true errors. So, if the user provides the right data and Stripe doesn't return an HTTP error then there is nothing to report other than success...	[reply]

Replies are listed 'Best First'.

Re^2: Error handling in a module
by Bod (Parson) on Feb 27, 2023 at 00:38 UTC

Unfortunately, I am not qualified to comment on how best to support and troubleshoot a Stripe Payment Gateway

The Stripe Gateway isn't really a problem - it can only do three things. 2 are normal behaviour and one is an error which I handle in the module.

It's the way my module handles errors that I am concerned with and I feel I am doing it a sensible way. I was more wanting to check that there wasn't a "better" way that I had overlooked and I am now satisfied that the way I've approached it is sensible and useful to anyone losing my module.

The 'errors' are more 'failed validation' of user input than true errors. So, if the user provides the right data and Stripe doesn't return an HTTP error then there is nothing to report other than success...

[reply]