Chas Owens wrote:
On 1/26/06, JupiterHost.Net <[EMAIL PROTECTED]> wrote:
The problem with defining your own versions of die, warn, croak, and
carp is that only your code uses them. If another module croaks or
Thats why you put it in a module and use it in all your scripts and if
it has not already been done and you can find a proper place for it to
go, out it on CPAN so every can use it.
You misunderstand my statement. Overriding the __DIE__ and __WARN__
handler affects all modules. Even the ones you didn't write (for
example the DBI module). This allows you to have your custom error
handling regardless of what called die, warn, carp, or croak.
Gotcha,
still if I needed ot do that I'd rather:
$SIG{__DIE__} = \&_die_to_email;
now you've got more readbality (especially if you do it right after use
strict and warnings in your script ;p) and the univerasl die() change
dies then your custom error handling is not used. This is why we have
access to $SIG{__DIE__} and $SIG{__WARN__} (croak() and carp()
internally use die() and warn() respectivly if I remember correctly).
You are still "defining your own versions of die, warn, croak, and carp"
and "only your code uses" still. Just differently :) but when you look
at it later is it die()ing lile normal or custom or ??? having a good
name for it makes it instantly recognizable and infinatelly easier to
maintain:
No, it makes it harder to maintain since someone else's code may
simply die() and you will lose the error handling. If you override
the signals you can control what happens when you die regardless of
what someone else does in the code. By the way, there is nothing to
stop you from saying:
$SIG{__DIE__} = \&my_custom_die;
Ah, great minds :)
I just prefer to use closures because I don't like global variables.
For example:
Say you're sorting through a 1200 line script I wrote 9 months ago and
find this:
die "oops I did it again: $!";
Now is it:
a) standard die
b) send the error to email
c) INSERT it into a database
d) write it to a file
e) format it for HTML
f) none of the above
g) ask me, the original author, and hope I remember what sort of crack
I was on that day (IE not gonna happen ;p)
Well, the answer is simple: it is the __DIE__ handler that was defined
by the script. If no __DIE__ handlers are defined then it is a simple
die(). There is no confusion (unless you are bringing it with you).
erm, i think I'm done with this thread, getting a little to attitudy for
me :) I already had to deal with the abuser of this address (mlists)
earlier this week, I'm finished :)
Imagine the same scenario but with your function there instead. How
are you better off? You can do a search for my_custom_die(), but you
can do the same search for __DIE__. All that has happened is that you
have lost the ability to control what foreign code does when it
croak()s or die()s.
I understand, no worries. The OP code was so hard to read I thought a
nicer readable
thing would help in figuring out what they heck they are trying to do in
the first
place instead of making it even harder to read.
Have a great day everyone.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
