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.
>
> > 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;
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).
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.
>
> However if it had been
>
> _die_to_email("oops I did it again: $!");
>
> _die_to_sql("oops I did it again: $!");
>
> _die_to_file("oops I did it again: $!");
>
> _die_to_html("oops I did it again: $!");
>
> Now I know *exactly* whats going on and pretty much where to look to see
> what its doing.
>
> Or at least, even _die("oops I did it again: $!"); (or in my initial
> example _my_die()) tells me its no normal die()
>
> You're right that %SIG is there so we can have our way with it (and is
> really handy when dealing with forks and children etc) but it doesn't
> mean we should (more ambiguous, more error prone, harder to maintain,
> etc etc)
>
>
> The bottom line is:
>
> - both ways are fine
> - using a function name that says what its doing makes it clear and
> easy to maintain
> - redefining the signal handlers is more ambiguous and problematic but
> allows you to change the behavior of built in exception handlers. (maybe
> more useful to add to a large existing script so it all of a sudden
> handles it how you want with only one change but past that feels more
> like a hack to me)
> - both ways make the OP's code way easier to read (what was the point
> of this thread originally anyway)
TIMTOWTDI, YMMV, etc.
My coding style tends to run towards large modules being manipulated
by small scripts. Having the rule that the modules should croak() or
die() (depending on whichever makes more sense in the context) and the
driver script should handle what happens works for me. Just to prove
that TIMTOWTDI here is another method that achieves a similar effect
using your custom function.
#!/usr/bin/perl
use ModuleA;
eval {
my $obj = ModuleA->new;
#do stuff
};
my_custom_die($@) if $@;
I just don't like cluttering up my code with try/catch blocks unless I
am actually catching the error (ie recovering).
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
