I'd like to try to improve my program's readability by standardising the way I return errors. I find my better programs are more than 50% error handling code, so I want to find a good way to standardise my error handling style. I've played around with a few concepts for this, but I haven't found one I really like yet.

I'm sure the other monks would have some good ideas on this, with readability and consistency being my most important objectives.

---

One approach I've used is to return a two-element array from every subroutine, with one value being the real return, and the other being an error. I can then call the subroutine thus:

($formatted_users,$error) = &format_output($users);
defined($error) && &fatal_error($error); 
        #logging/feedback to user
[download]

The disadvantages of this approach are:

• I must test for errors between each subroutine call, so I can't do nested calls. For example, I can't do:

  $formatted_users = &format_output(&get_users($fh));
  [download]

• I have to force all return values into a scalar, making elegant returns based on wantarray impossible.
• I think the frequent reference to errors breaks the flow of the program for a reader.

With regard to the final point, I've always been a huge fan of the way perl determines a truth/falsehood for each expression, since it allows much more elegant referencing to errors, eg:

($formatted_users = &format_output(&get_users($fh))) 
    || &fatal_error("something went wrong formatting the users");
[download]

In this example, &format_output would return undef if there was any error, making the truth value of the assignment false, and causing the error code to be executed.

The disadvantage of this approach is the granularity of the error message. The message isn't generated inside the subroutine, so it doesn't tell you why something went wrong.

So, the next idea I had been tossing around was to use a global error value, sort of a home-made $! (error indicators). Then I could do something like this:

($formatted_users = &format_output(&get_users($fh))) 
    || &fatal_error($ERR);
[download]

which gives the user lots more information, and keeps the code compact and readable. $ERR might even be a hashref with fields like $ERR->{severity} and $ERR->{send_email}. It might be imported from a package, if the sub belonged to a foreign package, eg

&user_delete || &fatal_error($user::ERR->{message})
[download]

Does anyone have any criticism for this last idea? What about other ideas? What about putting my error inside $ENV? Perhaps using signals?

---

---

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.