I'm writing a module to go with Business::Stripe::WebCheckout that will deal with Stripe subscriptions. (Yes - I have written tests before writing the code!)

The way the previous module deals with errors follows the way DBI mostly does it. If there is an error, it keeps it quiet and carries on. My module relies on the code using it to call success to check the operations worked out and calling error to find out what went wrong.

Currently, the new module uses the same approach. But I am wondering if I should use some other way to detect errors. I've looked back a decade to Re: Error handling and there is some good advice but it doesn't cover modules per see. Also, wisdom can change in a decade...

Here's my reasoning for doing it the way I am. Can you pick fault with it so that together we can find a better way or be confident that the current methodology is fine?

• As the module connects with Stripe, it is only ever going to be used in a CGI environment. Therefore, the end user will be a web visitor. My concern is not the user experience of the end user. It is that the person who creates the web experience has an easy time of making a good user experience for the end user.
• Throwing an error to STDERR is not very helpful in a CGI environment
• Throwing an error with die and stopping the web experience completely is not a very good solution because the error that will be displayed is probably meaningless to the end user.
• Taking the end user through to the Stripe checkout with no information is not helpful to anyone. 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. But, if they choose not to check, it won't take the end user off to Stripe unless all the required information is present.

Maintaining compatibility and consistency with Business::Stripe::WebCheckout is not an issue as there needs to be a new version of that soon. I've learnt a lot since publishing that, a couple of people have made suggestions for extra functionality and Stripe have released a newer version of their API. The new version will adopt the error handling of the new, unpublished as yet Business::Stripe::Subscription.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.