Not expected arguments for $SIG{__WARN__} handler #14917
Comments
From @KES777Created by @KES777The [doc](http://perldoc.perl.org/functions/warn.html) says: Bug when I call warn: warn 'arg1', 'arg2'; I expect to see two arguments in __WARN__ handler, but there is only one perl -E ' warn @_; warn "arg1", "arg2"; If we need ( we do!) the line where 'warn' occour then So calling 'warn @_' again will not break anything Perl Info |
From zefram@fysh.orgKES wrote:
The message is a single object, not a list. The list concatenation is But there is a related definite documentation bug. You raised the # If the last element of LIST $ perl -lwe 'warn "foo\n", ""' The ending newline is actually looked for in the concatenated message, -zefram |
|
The RT System itself - Status changed from 'new' to 'open' |
From @KES777ZvR> The ending newline is actually looked for in the concatenated message, Seems same to me. The concatenated message actually is the list with one element. The question is why arguments are changed? This call 'warn' -> trigger this sub '$SUB{ __WARN__ }' What is the reason to merge arguments? ( I agree they must be merged when it is ready to send the message to destination (to STDOUT), but it is traveling yet to destination. And we must have a good reason to change args) -- |
From @ap* Eugen Konkov <kes-kes@yandex.ru> [2015-09-19 07:25]:
You misunderstand what is going on. $SIG{__WARN__} is called any time the warnings system is about to output These warnings do not have to come from `warn`. They can be any warnings The job of `warn` is to take its arguments and turn them into a message If you want to intercept the arguments to `warn`, then that is what you Chapter �Overriding Built-in Functions� in `perldoc perlsub` explains Regards, |
From zefram@fysh.orgThe documentation regarding looking for newline was fixed in commit -zefram |
From @KES777Zefram, in your commit you have a small typo: You miss "s" 16.12.2017, 08:25, "Zefram via RT" <perlbug-followup@perl.org>:
|
From zefram@fysh.orgKES wrote:
Thanks. Fixed in commit 6f0a679. -zefram |
From @KES777Zefram, thank you for clarifying the DOC. But one question:
Are you speaking about warnings or exceptions here? if you are speaking about exceptions then "a L<C<$SIG{__DIE__}> handler" should be installed instead of $SIG{__WARN__}. Aristotle Pagaltzis
The message given to the warnings systems is $@, is not? So I will advocate to that that handler should be called with original LIST
Never thought about overloading because "this behaviour can be altered by installing a L<C<$SIG{__WARN__}>|perlvar/%SIG> handler." so maybe there will be a good point to describe the difference between installing the handler and overloading the CORE::warn |
From zefram@fysh.orgKES via RT wrote:
Both. The subject of warn() is an exception, in the sense of being a
warn() can take an exception from $@, but within the warning system the -zefram |
|
@xsawyerx - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release yesterday of Perl 5.28.0, this and 185 other issues have been Perl 5.28.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#126085 (status was 'resolved')
Searchable as RT126085$
The text was updated successfully, but these errors were encountered: