In
jettero's recent post,
STDERR, he was attempting
to solve a problem that wasn't really a problem. Or, in
short, his own answer to his problem was a singular effective
solution which may introduce further problems if a case
exists where he doesn't want to have a certain action
associated with warnings. Admittedly, he can simply
override the action and restore it after he handles the
warning in the other manner. But it got me to thinking if
this was a good way to handle it.
I was actually asked by footpad to take a look at the
thread and to see if any good answers had been posted (most
notably his :). That's why I posted Re: STDERR. I felt
that in the overwhelming rush to find an answer, everybody
overlooked the fact that the warnings were being produced
from failed database statements via the DBI. Furthermore,
the DBI already has mechanisms in place to handle errors
(and this is where my answer came from).
So, I think the questions I want to ask are as follows:
- If you select a module as the way you're going to do it,
have you effectively chosen to limit yourself, in regards to
the task the module performs, of the ways by which you attempt
to solve your tasks?
- What takes precedent, the API defined by the module or
the spec which says do X with all errors? In essence, I tend
to use the $DBI::errstr when it is populated to determine
action, but why aren't there hooks in the connect string to
allow overridden exceptions? (rhetorical question...)
What do/have you thought about the self imposed
restrictions when using well defined modules with good APIs?
Is it always necessary to follow the rules? Is it better to
follow just in case you forget why you broke them?
ALL HAIL BRAK!!!
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: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.