我想替换print STDERR
我的代码库中的现有语句。
显然,我发现它们不太适合眼睛,或者只是我。我是否应该warn
知道它将被$SIG{_WARN_}
处理程序捕获。或者有没有更好的选择。如果是,为什么要使用这些选项而不是print STDERR
.
我想替换print STDERR
我的代码库中的现有语句。
显然,我发现它们不太适合眼睛,或者只是我。我是否应该warn
知道它将被$SIG{_WARN_}
处理程序捕获。或者有没有更好的选择。如果是,为什么要使用这些选项而不是print STDERR
.
这样做的好处print STDERR
是您可以立即看到会发生什么——您将某些内容打印到 STDERR。这可能是一条调试消息,或者其他什么。
warn
功能略有不同:
您可能应该将其用于警告,而不是用于记录数据
您可能还对Carp
函数族感兴趣。carp
像 一样工作warn
,但从调用点报告行号/文件。cluck
将warn
带有堆栈跟踪。
但没有什么能阻止你自己滚动。一个功能等效的 sub toprint STDERR
将是:
sub debug { print STDERR @_ }
你现在可以从字面上看s/print STDERR/debug/g
你的来源,除了那一次。debug
此外,如果您希望能够省略参数周围的括号,则必须在使用该函数之前声明或导入该函数。
debug "this ", "is ", "DATA";
需要考虑的一点:调用 sub 很慢,而调用的print
是内置操作码。你可以用美丽换取性能,反之亦然。
创建debug
要包装的子例程print STDERR
将为您提供比简单print
orwarn
语句提供的更多灵活性,例如关闭调试消息或将它们重定向到不同目的地的能力。例如,就在我的脑海中:
sub debug {
my ($msg, %param) = @_;
$param{level} //= 1; # default if no level specified
return if $param{level} < $config{log_level};
given ($param{dest}) {
when ('mail') { send_email_to_admin(subject => "Application Error!", body => $msg) }
when ('log') { write_to_logfile($msg) }
default { print STDERR $msg }
}
}
debug('foo'); # goes to STDERR by default
$config{log_level} = 2;
debug('bar'); # message is ignored as unimportant at current logging level
debug('bar', level => 3, dest => mail); # still important; gets emailed to admin