HTTP/2 200 cache-control: max-age=43200 server: Combust/Plack (Perl) vary: Accept-Encoding content-encoding: gzip content-length: 2037 content-type: text/html; charset=utf-8 last-modified: Sun, 12 Oct 2025 06:54:03 GMT traceparent: 94015c9ef7016ccd7ffe3aff10e37fb7 strict-transport-security: max-age=15768000 Front page | perl.perl5.porters | Postings from December 2014

Re: Is the warning fatalization mechanism in fact safe (specificalyFATAL => 'ununitialized')

Thread Previous | Thread Next

On 12/27/2014 04:28 PM, Father Chrysostomos wrote:
> Peter Rabbitson wrote:
>> Over the years I have heard several off-the-record remarks that the
>> FATAL warning mechanism is in fact rather broken and can not be relied
>> upon. Problems described ranged from "both warning and exception will
>> disappear in the ether" to "will corrupt the callstack in cases of
>> DESTROY-unwind FATAL warnings".
>
> There have been several bugs in core with fatal warnings preventing
> things from happening that should have happened already, such as file-
> test operators not setting $!.  There also used to be memory leaks.  I
> think I have fixed all those.
>
> Fatal warnings can blow the top off the C stack inside a destructor.
> See bug #123398.
This is not fixed yet, correct?
>
> Apart from that, fatal warnings are no worse than errors thrown by
> tied variables, which, indeed, can cause eval{} not to catch an error,
> which can be very confusing.  See bug #105916.
>
You seem to be rather well-versed in this area of perl. It would be 
*invaluable* if you could put together a list of all RTs (fixed and 
unfixed), pertaining to FATAL warnings.
The fixed ones are actually even more interesting, because these points 
of differing behavior between different versions of the perl interpreter.

Thread Previous | Thread Next

• Is the warning fatalization mechanism in fact safe (specificaly FATAL=> 'ununitialized') by Peter Rabbitson
• Tally of issues with FATAL warnings / RFC to explicitly discouragetheir use by Peter Rabbitson
• Re: Tally of issues with FATAL warnings / RFC to explicitlydiscourage their use by Zefram
• Re: Tally of issues with FATAL warnings / RFC to explicitlydiscourage their use by Jesse Luehrs
• Re: Tally of issues with FATAL warnings / RFC to explicitlydiscourage their use by David Golden
• Re: Is the warning fatalization mechanism in fact safe (specificaly FATAL => 'ununitialized') by Father Chrysostomos
• Re: Is the warning fatalization mechanism in fact safe (specificaly FATAL => 'ununitialized') by Father Chrysostomos
• Re: Is the warning fatalization mechanism in fact safe (specificalyFATAL => 'ununitialized') by Peter Rabbitson
• Re: Is the warning fatalization mechanism in fact safe (specificaly FATAL => 'ununitialized') by Father Chrysostomos
• Re: Is the warning fatalization mechanism in fact safe (specificalyFATAL => 'ununitialized') by bulk88
• Re: Is the warning fatalization mechanism in fact safe (specificalyFATAL => 'ununitialized') by demerphq
• Re: Is the warning fatalization mechanism in fact safe (specificalyFATAL => 'ununitialized') by Peter Rabbitson
• Re: Is the warning fatalization mechanism in fact safe (specificalyFATAL => 'ununitialized') by Rafael Garcia-Suarez
• Re: Is the warning fatalization mechanism in fact safe (specificalyFATAL => 'ununitialized') by Peter Rabbitson
• Re: Is the warning fatalization mechanism in fact safe (specificaly FATAL => 'ununitialized') by Father Chrysostomos