Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Yet Another Override Oddity

by Zaxo (Archbishop)
on Apr 28, 2005 at 03:57 UTC ( #452208=perlmeditation: print w/replies, xml ) Need Help??

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,

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.


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 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 <>

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://452208]
Approved by friedo
Front-paged by virtualsue
[Aristotle]: gosh I havenít been here in such a long time

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (5)
As of 2017-02-27 02:41 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (376 votes). Check out past polls.