Re: [log4perl-devel] should Log::Log4perl::Config::config_read call die ?

[Wiggins d'A. <wi...@da...>]

Mike Schilli wrote:
> On Tue, 13 May 2003 lei...@hp... wrote:
> 
> 
>>I am not sure if this has been raised before, the sourceforge mail list
>>browse doesn't have a search function, so I just checked the last 100
>>messages.
> 
> 
> Look at the upper left corner. There's a search field and a select box with
> the item "This Mailing List":
> 
>     http://sourceforge.net/mailarchive/forum.php?forum_id=10175
> 
> 
>>I suppose I would call this more an issue of style - I have issues with any
>>library that exits on me. I would prefer a library told me 'sorry I cant
>>help you' and let me decide on the flow from there.
>>...
>>An eval could help - in fact there are many 'workarounds' - but I still feel
>>calling die is wrong.
>>
>>Are there any plans for this behaviour to be revised in the future ??
> 
> 
> It's a trade-off to protect against people not checking the return code of
> init() and then wondering what's wrong. A matter of style, indeed, and
> negotiable.
> 
> One area which is tougher to solve is with init_and_watch(). What happens
> if Log4perl reloads the conf file and somebody has put a syntax error
> in there? There's no application interaction at this point, no way to
> catch this error but die. I think this particular issue also drove the
> decision to die() on a failed init().

I had wondered about this last part (init_and_watch) while trying to 
bullet proof our app. Would it be possible to do something along the 
lines of:

1) Store old configuration
2) Read new configuration
   a) succeeds replaces old configuration (like current)
   b) fails: calls handler, resumes with original configuration

Then the author would supply 'init_and_watch' with a handler (code ref) 
that would be called if the new configuration couldn't be loaded. Seems 
like this is an easy way to alert the user, keep the app running, and 
still be able to log (albeit under the original configuration). Don't 
recall if init_and_watch is configurable from a file, that could 
conceivably cause some problems (aka putting a bad handler in the config 
file, etc.)....

The die I don't mind on the 'init' since it can be caught and that seems 
to be a direction a number of modules are moving in, but the 
init_and_watch is an interesting issue.

http://danconia.org