Mailing List Archive: Warning catchers. Was

Sorry if I'm duplicating ideas here. My feed of perl5-porters is stalled
for local reasons, so I'm only seeing items on this thread Cced to me.
(i.e. please leave me on Cc list)

Gurusamy Sarathy <gsar@engin.umich.edu> wrote:

> On Tue, 12 Dec 1995 08:40:36 MST, Tom Christiansen wrote:

> >> no warn qw(W2_UNINIT W2_BARESTR);
> >that's not very pretty.

If we're having that sort of constant, I don't see any point in having
the W2_ prefixes. Isn't it about time for Perl to have enumerated types? :-)

> >but the __WANR__ hooks aren't nicely stackable, so that
> >might be problematic (see diagnostics.pm or CGI::ErrorWrap)

OK - here's another idea, with more UNIVERSAL:: pollution.

A warning should send a __WARN__ message to the current package (ditto a
fatal error), and &UNIVERSAL::__WARN__ should implement the current
behaviour. Setting $SIG{__WARN__} is tantamount to redefining
&UNIVERSAL::__WARN__, although backwards compability would demand a
different parameter list.

__DIE__, too, mutatis mutandis.

Advantages - we already have a mechanism for inheritance. No new
overhead on entering and leaving packages.

Disadvantages - an escape hatch may be needed if things go seriously
wrong, but presumably this applies already. We gain cruft in the form
of two different methods of catching warnings.

> A module like diagnostics could request special treatment (if no
> other module is already getting it) to force itself into
> the bottom of the stack so it sees only the warn messages
> from perl itself.

This falls out of the method-based solution.

Ian

On Tue, 12 Dec 1995 18:29:55 GMT, Ian Phillipps wrote:
>> >> no warn qw(W2_UNINIT W2_BARESTR);
>> >that's not very pretty.
>
>If we're having that sort of constant, I don't see any point in having
>the W2_ prefixes. Isn't it about time for Perl to have enumerated types? :-)
>

OK, no prefixes.
Let me know when you have true enumerated types. :-)

>
>OK - here's another idea, with more UNIVERSAL:: pollution.
>
>A warning should send a __WARN__ message to the current package (ditto a
>fatal error), and &UNIVERSAL::__WARN__ should implement the current
>behaviour. Setting $SIG{__WARN__} is tantamount to redefining
>&UNIVERSAL::__WARN__, although backwards compability would demand a
>different parameter list.
>

Sounds like an interesting, orthogonal idea.

>> A module like diagnostics could request special treatment (if no
>> other module is already getting it) to force itself into
>> the bottom of the stack so it sees only the warn messages
>> from perl itself.
>
>This falls out of the method-based solution.
>

I don't see how diagnostics.pm can trap warnings from perl
if a package implements the __WARN__ method. Such a package
would always get the first stab at the warning, and then,
if it cooperates, it will call SUPER->__WARN__ which might
cascade down to UNIVERSAL::__WARN__, at which point diagnostics.pm
will be able to see it.

I also don't see (you'd think I'm blind or sumthin') why the two
approaches can't coexist, but the big question is: are we using
a cannon to shoot down a mosquito?

- Sarathy.
gsar@engin.umich.edu