Error handling and application logging are the most import tasks associated with programming that are over looked by many developers.
After a program is released to the field, how do you know if it is performing as it should? Are there issues with the language execution (1-tier), with the database (2-tier) or with the middle-ware (3-tier) ? Many times, issues are only noticed and acted upon after several complaints have been issued.
Here is a short list of why you should adding logging to all programs that you create.
- Traps program execution for tracing down coding causing the error.
- Traps error events for follow up by developers before users complain.
- If captured in windows event log, 3rd party tools can harvest logs to one central server.
- Dashboards created at the central server can show the heart beat of your whole infrastructure.
The original application logging CLASS that I wrote in Visual Basic writes to both a local file and the windows event log. There is no equivalent PERL PACKAGE that does just that. Therefore, I am going to build the PERL package to over come this deficiency.
The following example creates a sample package named MyLog to write a string to a file.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 |
# # Define package name / export variables # # My package name package MyLog; # Export name space require Exporter; our @ISA = qw(Exporter); # # Define local variables. # # Data element 1 my $FileName = ''; # Data element 2 my $Message = ''; # # Define properties # # Set file name sub SetFileName { my ($var) = @_; $MyLog::FileName = $var; return; } # Set message sub SetMessage { my ($var) = @_; $MyLog::Message = $var; return; } # # Define methods # # Write to log file sub WriteToTxtFile { # Open the text file open(OUT, ">>$MyLog::FileName"); # Create the string my @aryData = localtime(time); my $Line = ''; $Line .= (1900 + $aryData[5]) . '-'; $Line .= (1 + $aryData[4]) . '-'; $Line .= $aryData[3] . ' '; $Line .= $aryData[2] . ':'; $Line .= $aryData[1] . ':'; $Line .= $aryData[0] . ' - '; $Line .= $MyLog::Message; # Write string print OUT $Line, "\n"; # Close the file close(OUT); # Just exit return; }; |
We need to tell PERL where our custom pakage is located by using the use lib statement.
1 2 3 4 5 |
# Set library path use lib 'c:\perl-depot\logs'; # Use perl module use MyLog; |
The new module is already in the name space of the PERL script. We just need to set the properties of the file name and message before calling the Write() method.
1 2 3 4 |
# Set properties & Write to logs MyLog::SetFileName('c:\perl-depot\logs\MyApp.log'); MyLog::SetMessage('This is a real error!'); MyLog::Write(); |
The table below has complete application logging code that you can use in your next PERL Script. I used the CPAN module (Win32::OLE) to leverage the Windows Scripting module. This technique opens up all the windows objects that you call in Visual Basic Script to PERL.
AppLog.pm | App Log Package |
tst-app-logging.pl | Sample App Log Program |
MyApp.log | Sample log file |
perl warning | Windows event entry |
In summary, creating user defined packages allows you to create objects that can be easily reused. In fact, an advance technique would be the compiling of the PERL package for distribute to others. This advance task is out of scope for this talk. Adding application logging to your scripts will save you time in the long run when there are application, database, middle-ware or network issues plaguing your company.