lr_warn and levels vs die and signal handlers in modules (was: Re: [COMMIT LOGREPORT] service/www/lib .cvsignore,NONE,1.1 Apache.pm,NONE,1.1 Makefile.am,NONE,1.1)

[Joost van Baal]

[Cc-ing the development list, since I feel this is a general development
discussion]

On Mon, Aug 27, 2001 at 09:48:50PM -0400, Francis J. Lacoste wrote:
> On Mon, Aug 27, 2001 at 09:43:16PM +0200, Joost van Baal wrote:
> > <snip>
> > >     ) = $rest =~ m!^ "([^"]+)" "([^"]+)"$!
> > >       or die "combined2dlf: can't parse referer and useragent fields\n";
> > 
> > Shouldn't this use lr_warn or whatever it's called?
> > 
> 
> If you look at combined2dlf (or all other scripts that use Apache.pm)
> they use eval to trap that exception and print the message using lr_warn.
> 
> Maybe we should discuss this. I have programmed all the new infrastructure
> using that kind of error handling : using exceptions. All perl modules
> use die to report error and warn to log non fatal exception. 
> 
> Programs that use those modules use eval to catch errors and deal 
> appropriately with them. Additionnally, all programs that use Lire::Program
> have a handler automatically setup for warn message that logs them using 
> lr_warn.
> 
> From the point of view of combined2dlf it makes no sense to continue from 
> that point, so it dies. For an hypothetical program that uses that function 
> to convert one line, die would also be a good policy. For our program that
> convert 5000 lines, we use eval to catch the exception and report the error.
> Having all library functions signal error with die has the advantage of
> simplifying the error handling. Most of the time, error handling will mean
> either logging it as a warning or terminating the program. This means that
> you will have :
> 
> eval {
>     do_this();
>     do_that();
>     do_also_this();
>     do_also_that();
> };
> warn $@ if $@;
> 
> instead of :
> 
> $status = do_this();
> warn "do_this() failed\n" && next if $status == $special_error_code;
> 
> $status = do_that();
> warn "do_that() failed\n" && next if $status == $special_error_code;
> 
> $status = do_also_this();
> warn "do_also_this() failed\n" && next if $status == $special_error_code;
> 
> $status = do_also_that();
> warn "do_also_that() failed\n" && next if $status == $special_error_code;
> 
> What I like with this approach is that it makes the library modules somewhat
> independant of the error handling / logging policy. Using warn and die to
> handle errors and warning is becoming more and more widespread (especially
> in modules that have object oriented interface). This means that we can 
> change the logging policy and do not have to change the way all library
> modules report errors. Die, warn and eval makes a maintainable, flexible and
> elegant solution, IMHO.

I agree.  However, you loose the granularity of emerg, alert, crit, err
and friends.  I believe level debug would be nice to use in the library
modules.  But we could deal with that, and still use your setup.  The fact
it's completely transparant (just use die and warn) is very nice indeed.

> If people like this approach, I can document it into the Developer's Manual
> so that it becomes part of the coding conventions. If not, I can change it,
> but we should have a section on error handling in the coding conventions.

The netto result is positive, so I'd say document it.  Anybody else would
like to share some thoughts on this?

Bye,

Joost


-- 
To UNSUBSCRIBE, email to development-request at logreport.org with a subject of
"unsubscribe". Trouble? Send an email with subject "help" to
development-request at logreport.org