The stupid question is the question not asked | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
All that I could really offer is “what works for me.” In pretty much all of my recent code, you’ll find this near the top:
If you search for these at http://search.cpan.org, you will see how each one of these work. I write code so that it either succeeds or it dies, and when it dies I prefer that it throw an exception-object so that it can carry a “payload” about exactly what happened, without me having to try to deduce it from a text-string. I also find it useful that, with the mechanisms cited above, I can get the traceback of called routines without at that moment spewing it out to STDERR. This allows me to, for example, get a truly useful diagnostic message in the Apache logs without, so to speak, throwing up on the web user’s screen. Specifically: I set up a hierarchy of exception-classes in one application-wide shared module. The outer-level loop of the program contains a “catch-all” handler which will intercept any exception that no one else has caught. Each significant block of code contains a surrounding exception-handling block, and it “re-throws” any hot potato that it does not itself know how to handle. My code is aggressively and constantly checking itself for errors, testing every assumption with an assertion, with the result that while it will throw a slew of errors during testing, the pattern is that “suddenly, and pretty much forevermore, it stops.” Each time I am shooting down another bug, I am always able to know with a fairly high degree of precision where to find it. (Which is, as the credit-card commercials say, “Priceless.”) Part of the perldoc which I dutifully write for every package/object is a discussion of the exception classes that this object may (directly) throw, and under what conditions it will do so. The exception is, as it were, “a possible output,” and the object’s contract with its caller is that, if it successfully returns control back to you, at all, then you can rely that it [thought in good faith that it] successfully did what it was told and returned a reliable answer. The package which contains all of the exception classes, in turn, dutifully contains a description of each one. In reply to Re: When throw exceptions?
by sundialsvc4
|
|