http://www.perlmonks.org?node_id=452208

Once more, a great answer has bit the dust in testing. I wanted to give jacques a different answer than I did to Using STDERR and timestamps to write to a log file, namely,

local *CORE::GLOBAL::die = sub (@) { die scalar(localtime()), ' ', @_; };
but die keeps on dieing the same old way.
$ perl -e'local *CORE::GLOBAL::die = sub (@) {CORE::die(scalar(localti +me()), " ", @_);}; die "Foo!"' Foo! at -e line 1. $

Apparently, die is not overridable. It has a prototype,

$ perl -e'print prototype "CORE::die"' @$
and it doesn't appear on diotalevi's toke.c list in Re: !Overriding Builtin print. Now how do we know which builtins are overridable? Is die somehow special-cased to not be overridden, as glob and readline are to permit it?

Overriding builtins is indeed a tricky business.

Added: Thanks, tye++ and leriksen++. You showed me something I didn't really understand before. It looks like builtins are outside both lexical and dynamic scope, being resolved sometime while compiling. Localizing them has no effect, and the last-compiled override is the one which counts. It's still a little freaky:

BEGIN { *CORE::GLOBAL::warn = sub (@) { CORE::warn(scalar(localtime), " ", @_); }; warn "Foo!"; } BEGIN { *CORE::GLOBAL::warn = sub (@) { CORE::warn( @_); }; } warn "Bar!"' __END__ Foo! at -e line 1. Bar! at -e line 1.
It looks like BEGIN blocks are all compiled to a single parse tree before they run, but that's only guessing.

After Compline,
Zaxo

Replies are listed 'Best First'.
Re: Yet Another Override Oddity (BEGIN)
by tye (Sage) on Apr 28, 2005 at 04:12 UTC

    Put a BEGIN block around the overriding and it works for me.

    - tye        

Re: Yet Another Override Oddity
by demerphq (Chancellor) on Apr 28, 2005 at 10:44 UTC

    As tye pointed out, you can override it in a BEGIN statement. But there is a point here, rewriting error messages like this is potentially evil. Error handling code very often depends on error messages being caught by eval and then parsed for certain constructs. Using $SIG{__DIE__} or die() to modify the messages potentially can interfere with this process.

    ---
    demerphq

Re: Yet Another Override Oddity
by leriksen (Curate) on Apr 28, 2005 at 06:25 UTC
    Yep, I went through exactly the same swamp here

    ...it is better to be approximately right than precisely wrong. - Warren Buffet

Re: Yet Another Override Oddity
by brian_d_foy (Abbot) on Apr 28, 2005 at 17:37 UTC

    The trick is to not use die(), and excise it from the code. Use your own subroutine (with its own name) and do whatever you like. People know to expect something different when they see a user defined subroutine name, but they most always expected documented behaviour when they see a Perl built-in.

    --
    brian d foy <brian@stonehenge.com>