There is an overwhelming amount of good advice in this post.

"Don't fail silently."

That can't be stressed enough, especially when dealing with critical data (in this case, financial).

"Like TDD, it's crucial to perform this error-handling analysis early because doing so will likely change your module's interface."

Truer advice has never been given. To me, writing my test platform is the most critical facet to interface design. It dictates it. I'm literally writing tests (nothing more than scripts that are true users of my software) that guides me to the end interface appearance. For me, my error messages (after so many years of coding) are generally logical, but through writing tests to cover edge cases, error messages become more refined, appropriate and understandable.

"with the module user expected to check this error property after calling each method."

Few will do that. You'll receive emails and bug tickets. Then you'll have to hand-hold to get someone to repro the issue which will never be the same again, and the bug goes unfound.

IMHO, a warning is something that you can let your users check for themselves. True errors however should be forefront. A user of the interface should have to do work to work around the error, not hear from someone that something isn't working causing all manner of teams to troubleshoot, then search out the error. Show them up front... somethings broken severely. It might be you, it might be me, but we can't continue until action is taken.

It is counter-productive to force users to go seek out whether there's an error under the hood or not. Break the caller, and allow them to decide whether they want to put an eval{} around it or not.

Failing silently is a nightmare and a frustration across the board.

Magnificent post, eyepopslikeamosquito!

-stevieb

In reply to Re: EyeBall stumps BodBall by stevieb
in thread EyeBall stumps BodBall (Error Handling) by eyepopslikeamosquito

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • 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! —
  • 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:
    & &amp;
    < &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.