¿Por qué `$ @` no es confiable?

Question

Me parece recordar que no es seguro confiar en el valor de $@ después de eval. Algo sobre un manejador de señal que tiene la oportunidad de establecer $@ antes de verlo o algo así. También estoy muy cansado y flojo ahora mismo para rastrear la verdadera razón. Entonces, ¿por qué no es seguro confiar en $@?

Answer 1

El Try::Tiny perldoc tiene la discusión definitiva del problema con $@:

There are a number of issues with eval.

Clobbering $@

When you run an eval block and it succeeds, $@ will be cleared, potentially clobbering an error that is currently being caught.

This causes action at a distance, clearing previous errors your caller may have not yet handled.

$@ must be properly localized before invoking eval in order to avoid this issue.

More specifically, $@ is clobbered at the beginning of the eval, which also makes it impossible to capture the previous error before you die (for instance when making exception objects with error stacks).

For this reason try will actually set $@ to its previous value (before the localization) in the beginning of the eval block.

Localizing $@ silently masks errors

Inside an eval block die behaves sort of like:

sub die { 
     $@ = $_[0]; 
     return_undef_from_eval(); 
} 

This means that if you were polite and localized $@ you can't die in that scope, or your error will be discarded (printing "Something's wrong" instead).

The workaround is very ugly:

my $error = do { 
     local $@; 
     eval { ... }; 
     $@; 
}; 

... 
die $error; 

$@ might not be a true value

This code is wrong:

if ($@) { 
     ... 
} 

because due to the previous caveats it may have been unset.

$@ could also be an overloaded error object that evaluates to false, but that's asking for trouble anyway.

The classic failure mode is:

sub Object::DESTROY { 
     eval { ... } 
} 

eval { 
     my $obj = Object->new; 

     die "foo"; 
}; 

if ($@) { 

} 

In this case since Object::DESTROY is not localizing $@ but still uses eval, it will set $@ to "".

The destructor is called when the stack is unwound, after die sets $@ to "foo at Foo.pm line 42\n", so by the time if ($@) is evaluated it has been cleared by eval in the destructor.

The workaround for this is even uglier than the previous ones. Even though we can't save the value of $@ from code that doesn't localize, we can at least be sure the eval was aborted due to an error:

my $failed = not eval { 
     ... 

     return 1; 
}; 

This is because an eval that caught a die will always return a false value.

Answer 2

La Try::Tiny docs tiene una muy buena lista de deficiencias eval/$@. Creo que podría estar refiriéndose a la sección Localizing $@ silently masks errors allí.

Answer 3

$@ tiene los mismos problemas que cada variable global tiene: cuando se establece otra cosa, pone a cero en todo el programa. Cualquier eval puede establecer $@. Incluso si no ve un eval cerca, no sabe a quién más podría llamarle uno (subrutinas, variables vinculadas, etc.).