[Koha-patches] [PATCH] debugify a warn
Joe Atzberger
joe.atzberger at liblime.com
Thu Oct 16 18:07:29 CEST 2008
In my opinion that condition is deserving of a warning in the log and should
not be conditional on $debug. It is not like the warns in regularly
processed blocks that were clearly intended for temporary debugging. This
one is a sanity check against *internal* error. You can see it is regarded
as more serious than the other user-input problems pushed to @errors.
--Joe
On Thu, Oct 16, 2008 at 11:44 AM, Galen Charlton <galen.charlton at liblime.com
> wrote:
> ---
> opac/opac-tags.pl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/opac/opac-tags.pl b/opac/opac-tags.pl
> index 3d5d5dd..2b9dfd7 100755
> --- a/opac/opac-tags.pl
> +++ b/opac/opac-tags.pl
> @@ -138,7 +138,7 @@ if (scalar @newtags_keys) {
> $counts{$biblionumber}++;
> } else {
> push @errors, {failed_add_tag=>$clean_tag};
> - warn
> "add_tag($biblionumber,$clean_tag,$loggedinuser...) returned bad result (" .
> (defined $result ? $result : 'UNDEF') .")";
> + $debug and warn
> "add_tag($biblionumber,$clean_tag,$loggedinuser...) returned bad result (" .
> (defined $result ? $result : 'UNDEF') .")";
> }
> }
> }
> --
> 1.5.5.GIT
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-patches/attachments/20081016/d991712d/attachment-0002.htm>
More information about the Koha-patches
mailing list