However, I will not call die. I find it frustrating when modules die.

-- Bod in Re^6: STDERR in Test Results

While I doubt Bod, hailing from (working-class) Coventry UK, would be permitted to enter the hallowed Long Room at Lords to hurl abuse at the Australian cricket team during the Ashes test match last weekend, I'm sure he won't be stumped by this meditation's title ... unlike monks from non-cricket-playing nations, doubtless unfamiliar with Bazball :).

Bodball, you may recall I once scolded you for asking "what should I test?" long after you'd released your module. I similarly urge you to get into the habit of thinking long and hard about your module's error handling well before you release it, and for the same reasons. Like TDD, it's crucial to perform this error-handling analysis early because doing so will likely change your module's interface.

Further to the excellent general advice you've already recieved from afoken, I'm interested to learn more about the errors you commonly encounter in practice when using your Business::Stripe::Webhook module. I also urge you to add an expanded "Error Handling" section to your module's documentation.

General Error Handling Advice

Don't fail silently. Failure is inevitable; failing to report failures is inexcusable. Failing silently causes the following problems:

• Users wonder whether something has gone wrong. ("Why did my order not go through?")
• Customer support wonders what caused a problem. ("The log file gave no indication of a problem")

Embrace your software's fallibility. Assume that humans will make mistakes using your software. Try to minimize ways for people to misuse your software, but assume that you can't completely eliminate misuse. Therefore, plan error messages as you design software.

-- General error handling advice from Google Error Messages course

Programming Tips

What should a function do if it cannot perform its allocated task?

• return a value indicating failure
• throw an exception
• terminate the program

Return failure when:

• an error is normal and expected (e.g. opening a file)
• an immediate caller can reasonably be expected to handle the failure

Throw an exception when:

• an error is so rare that the programmer is likely to forget to check for it
• an error cannot be handled by the immediate caller
• new kinds of errors are added in lower modules that higher level modules were not written to cope with
• no suitable return path for error codes is available (e.g. semipredicate problem)
• return path of a function is made uglier by the need to return an error indicator
• the function that found the error was a callback
• an error requires an "undo" action (unlike RAII say)

This is not a black and white issue. Experience and good taste are required.

Business::Stripe::Webhook Error Handling

Though unfamiliar with your Business::Stripe::Webhook domain, I briefly browsed your module's documentation. Good to see you've already written a short "Errors and Warnings" section in its documentation; I suggest you improve and expand this section for the next release.

AFAICT, your basic error handling strategy is for your methods to set the error property, for example:

$vars{'error'} = 'Missing payload data'
[download]

with the module user expected to check this error property after calling each method. Is that right?

I think a clear statement of your overall error-handling strategy, combined with a couple of real-world examples of handling common errors you've experienced when using your module, would be invaluable to your users ... and may cause you to tweak your module's error-handling code and interface ... which is why this step is ideally performed well before release. :)

See Also

• Class invariant
• Design by contract
• RAII
• Dispose pattern (primarily used instead of RAII in languages with automatic garbage collection, e.g. Java/C#)
• perldiag

Updated: minor changes to wording were made shortly after posting. Added more references to the See Also section.

---

---

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.