Error Handling

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Error Handling by McDarren (Abbot) on Jan 16, 2006 at 03:32 UTC
File::Tail might be what you want.	[reply]
Re: Error Handling by davido (Cardinal) on Jan 16, 2006 at 03:50 UTC
I'm a little confused at what is writing to the logfile, and whether it only contains a list of errors or not. If you're fortunate enough to have a logfile that only contains error messages, all you have to do is keep track of its most recent modification time, or of any size changes. If it gets modified, or if it grows, that means a new error got logged. If it's not that simple, could you make it that simple by ensuring that errors get logged to some other file too? If that's not possible, maybe you could use File::ReadBackwards on the logfile and keep reading until you find the most recently reported error message. If, before arriving at that most recently reported error message, other error messages are also discovered, keep track of them and they'll be the basis for your imminent email report. Dave	[reply]
Re: Error Handling by graff (Chancellor) on Jan 16, 2006 at 05:15 UTC
The previous replies assumed that when one of your scripts "keeps a log of its output", this means it is always appending to a single log file every time it runs (so the log file gets longer with every run). If that's what you meant, then one idea would be: `# check the size of the log before the main script starts # check the size again after the logging "sub" scripts are done # if the log has grown, # open it, seek to the original size (start of new data) # read everything that was appended on this run. # filter out anything that you know does NOT describe an error # mail the remainder to interested recipients.` [download] On the other hand, it occurred to me that the script that logs its output might just be creating a new log file on each run, in which case the same strategy would work, without having to check the log file size first or seek to the start of the current output -- just read the whole log file. The important thing is to start by identifying and removing the stuff that people really don't need to see; if some irrelevant stuff gets through, that's less of a problem than failing to identify and keep all the possible relevant data. And it'll be easier to add to the set of irrelevant patterns to be deleted as people get tired of seeing them...	[reply] [d/l]
Re: Error Handling by tirwhan (Abbot) on Jan 16, 2006 at 08:07 UTC
If this were my script I probably wouldn't do the runaround of log file parsing but rather put the email functionality into the logging subroutine/method of the script itself. There are ten types of people: those that understand binary and those that don't.	[reply] [d/l]
Re: Error Handling by glasswalk3r (Friar) on Jan 16, 2006 at 14:05 UTC
If you just need to grab the error from the child script (instead of reading the log file) then my tip should help you. Design your application to delegate the error message to somebody else. You can do it by using sockets, IPC or any other mechanism that you think fits better into your application. For example, all scripts called by your main script will delegate the error messages by writting their respectives error messages to a different text file. The main script can check for those and send an email if necessary. This is far easier than trying to read a single log file (and probably having problems with file concurrency). If you have access to the scripts code (and time) I would suggest you to take a look at Log4Perl module. Alceu Rodrigues de Freitas Junior --------------------------------- "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill	[reply]