[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