Oh, goodness no :) But it's a good way to make sure we see what warnings are produced and whether or not we should be concerned with them.In fact, I wouldn't mind catching any warnings either.
in development you could set perl to die on all warnings and capture them that way. use warnings FATAL => 'all'; But I wouldn't run that in production...
The ultimate goals of this are to:
1) log information and errors to a table so we can analyze our application in development and production
2) for development, show a popup after each request with any errors or warnings produced, benchmarking data, HTML errors, etc. that were produced over the course of that request.
I've implemented the latter using the Log::Dispatch::Buffer module, and so far so good. I can easily store up all of the log messages as the application runs, and dump them out with L::D::B's fetch() method. If your plugin is implemented as a singleton, I just have to make sure I call flush() at the end of each request ;)
Your singleton implementation idea looks simply beautiful. I do have to say the present implementation is just as nice. Very nice, easy-to-use interface.
In the end, either solution is acceptable for what I'm doing. I don't think any of the warnings we produce are worth logging (and I probably shouldn't be so concerned), but I can't help being paranoid about such things ;)
Let me know if you decide to change your implementation. I'd be happy to beat on it for you.
Thanks for your reply and ideas! Jason
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
