Bug #1218 for Config-General: warning message when interpolating undefined variables

Mon Jul 01 10:08:34 2002 Guest - Ticket created

Subject:

warning message when interpolating undefined variables

perl 5.005.003 Lynx Config::General 2.03 release perl -wT When interpolating an undefined variable with warning enabled, perl is trapping the error verses being caught by Config::General::Interpolate:_var (line 75) directly. It would be nice if this warning was caught and thrown with a different message than the perl standard so it can be identified differently. This error is really an user error and not a warning. Either the warning should be caught and ignored or some other error message thrown. It would also be nice if there was more control over error and warning message generation. It would be nice if the caller can specify the functions to call . I am writing a CGI application and I have croak, warn defined for the web. I don't want the errors generated from Config::General to go out to the web without additional explanations. Input file Root___Directory=xxxx Directory=${Root_Directory}/yyyy

Tue Jul 02 18:48:22 2002 Guest - Correspondence added

From:

tlinden [...] cpan.org

Hello, [guest - Mon Jul 1 10:08:34 2002]: Show quoted text

> When interpolating an undefined variable with warning enabled, perl is > trapping the error verses being caught by > Config::General::Interpolate:_var (line 75) directly. > > It would be nice if this warning was caught and thrown with a > different message than the perl standard so it can be identified > differently. This error is really an user error and not a warning. > Either the warning should be caught and ignored or some other error > message thrown.

The latest version 2.04 fixes this issue. It still throws an error but by itself, i.e.: "Use of uninitialized variable $blah". Check it out. Show quoted text

> It would also be nice if there was more control > over error and warning message generation. It would be nice if the > caller can specify the functions to call .

Sorry, I won't do that. Throwing errors using croak() is the standard behavior of perl modules. I will not change this. Show quoted text

> I am writing a CGI application and I have croak, warn defined for the > web. I don't want the errors generated from Config::General to go > out > to the web without additional explanations.

While offtopic, you could catch those errors using an eval{} block. Each message from some croak() in some module can be catched this way. And you can still decide, what to do afterwards. Example: eval { # .. some perl code, i.e. call Config::General::new() }; if($@) { # yes, an error occued. $@ contains the message &logger($@); # i.e. log the whole message to a logfile &print_error("404 Fatal error."); # tell the user, but say nothing } else { # processing inside the eval {} block worked well... } Kind regards, Tom

Sat Aug 03 18:00:09 2002 tlinden [...] cpan.org - Status changed from 'new' to 'resolved'