in reply to RFC: Log::Painless

Looks like you might benefit from Sub::Exporter. That way, people can alias your methods into names they like, so they can avoid clashes.

Other than that, it does look pretty nice; I like the way you intercept warnings and exceptions, although I wonder how well that plays with CGI::Carp, or Error other such modules.

But I'm going to stick with Log::Dispatch; I absolutely adore its features and plugins. Couldn't imagine life without Log::Dispatch::File::Rolling or Log::Dispatch::Email::MIMELite to direct my log messages.

Replies are listed 'Best First'.
Re^2: RFC: Log::Painless
by radiantmatrix (Parson) on Mar 15, 2006 at 19:47 UTC

    Thanks for the pointer on Sub::Exporter. Providing a custom-naming convention for imported routines is an interesting idea, and one I will be pursuing further (though maybe not in the initial release).

    Signal handlers *are* always tricky. If a module like CGI::Carp takes similar steps to "play nice", as I have, all should be ok, since I try to chain any pre-existing signal handlers. If they don't, then it's a matter of import order: if Log::Painless is imported last, it should record the log entry first, then call out to pre-existing ones.

    I've been struggling with how to mitigate these issues... perhaps I will simply allow the user to turn off the warn/die interception, with the caveat that warnings and exceptions would then have to be logged "by hand" through calling the exception and warning subs (which would have to be imported, then). I'm definitely open to suggestions on how to handle this -- it's got me a bit stumped.

    I do like Log::Dispatch, and I don't think Log::Painless would ever compete with it -- slightly different niche, I think.

    <-radiant.matrix->
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
[reply]
[d/l]
[select]

In Section Meditations