Re: [Koha-devel] warnings (was: [Koha-patches] [PATCH] kohabug 2345: bad comparisons pervade reports)
On Thu, Jul 31, 2008 at 8:06 AM, Galen Charlton <galen.charlton@liblime.com> wrote:
Now imagine what would happen if we (as we should) turn on warnings in Koha. I'll make a proper 3.2 RFC for it shortly, but IMO we really need to start putting in 'use warnings' in a all scripts. Many bugs have already been fixed that were based on undef scalars that should have had a value, and many more undoubtedly lurk.
Hi Galen - I'm looking forward to that RFC and hearing any resulting discussion. At the risk of opening up the discussion too early, I'll say that I'm glad to hear that I'm not the only one with that opinion on 'use warnings' (and 'use strict'!). -Andy
Andrew Moore wrote:
On Thu, Jul 31, 2008 at 8:06 AM, Galen Charlton <galen.charlton@liblime.com> wrote:
Now imagine what would happen if we (as we should) turn on warnings in Koha. I'll make a proper 3.2 RFC for it shortly, but IMO we really need to start putting in 'use warnings' in a all scripts. Many bugs have already been fixed that were based on undef scalars that should have had a value, and many more undoubtedly lurk.
Hi Galen -
I'm looking forward to that RFC and hearing any resulting discussion. At the risk of opening up the discussion too early, I'll say that I'm glad to hear that I'm not the only one with that opinion on 'use warnings' (and 'use strict'!).
Enterprise perl (LAMP) apps I have worked on demand the following: - "use strict" in every module and script - "use warnings" in every module and script - during testing: monitor error log(s); there must be ZERO entries written by the app to the log and no debug information when going into production cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor When the power of love overcomes the love of power, the world will know peace. -- Jimi Hendrix
On Thu, Jul 31, 2008 at 10:56 PM, Rick Welykochy <rick@praxis.com.au> wrote:
Andrew Moore wrote:
On Thu, Jul 31, 2008 at 8:06 AM, Galen Charlton <galen.charlton@liblime.com> wrote:
Now imagine what would happen if we (as we should) turn on warnings in Koha. I'll make a proper 3.2 RFC for it shortly, but IMO we really need to start putting in 'use warnings' in a all scripts. Many bugs have already been fixed that were based on undef scalars that should have had a value, and many more undoubtedly lurk.
Hi Galen -
I'm looking forward to that RFC and hearing any resulting discussion. At the risk of opening up the discussion too early, I'll say that I'm glad to hear that I'm not the only one with that opinion on 'use warnings' (and 'use strict'!).
Enterprise perl (LAMP) apps I have worked on demand the following:
- "use strict" in every module and script
- "use warnings" in every module and script
- during testing: monitor error log(s); there must be ZERO entries written by the app to the log and no debug information when going into production How do those apps deal with the 'uninitialized variable' warnings that are so pervasive in Perl apps? 'no warnings uninitialized' perhaps?
Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua Ferraro wrote:
How do those apps deal with the 'uninitialized variable' warnings that are so pervasive in Perl apps? 'no warnings uninitialized' perhaps?
I never allow uninitialised variables in my perl code. It is simply better to be consistent across all programming languages I use and make that the "best practice". Can you give me an example where an uninitialised variable is *necessary* to get a perl code segment working? So far, I have always found a way to avoid that warning message. And when I see it, I fix the problem. More thoughts on error_log: I have had great trouble finding "interesting" errors and warnings in the Koha error log due to the excessive amount of DEBUG messages from Koha and warnings from Perl and the MySQL DBI. Has consideration been given to a global debug(string) function that can be used to control the printing of debug information? Or even debug(string,debuglevel) ? cheer rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor When the power of love overcomes the love of power, the world will know peace. -- Jimi Hendrix
Hi Rick, On Fri, Aug 1, 2008 at 12:11 AM, Rick Welykochy <rick@praxis.com.au> wrote:
More thoughts on error_log: I have had great trouble finding "interesting" errors and warnings in the Koha error log due to the excessive amount of DEBUG messages from Koha and warnings from Perl and the MySQL DBI.
Agreed.
Has consideration been given to a global debug(string) function that can be used to control the printing of debug information? Or even debug(string,debuglevel) ?
Take a look at C4::Debug. This module is a start at exactly that. As we work through the code currently, we make every attempt to conditionalize debug warns based on C4::Debug. One goal as we head toward 3.2 is (I believe) to gain complete control over all debug warns and remove all useless warns. Kind Regards, -- Chris Nighswonger LibLime www.liblime.com chris.nighswonger@liblime.com
On Thu, Jul 31, 2008 at 11:11 PM, Rick Welykochy <rick@praxis.com.au> wrote:
More thoughts on error_log: I have had great trouble finding "interesting" errors and warnings in the Koha error log due to the excessive amount of DEBUG messages from Koha and warnings from Perl and the MySQL DBI.
Has consideration been given to a global debug(string) function that can be used to control the printing of debug information? Or even debug(string,debuglevel) ?
I agree, that's one of our "areas for improvement". I've had great success using Log4perl before. It lets you configure how much of any particular type of these warnings and error messages and debug information you get at any time. Maybe somewhere down the road I'll see if I can plug it into C4::Debug somehow and try to tame these messages. -Andy
participants (4)
-
Andrew Moore -
Chris Nighswonger -
Joshua Ferraro -
Rick Welykochy