in reply to Moving Log files remotely

Just a note on error handling:

Maybe it's because I've been writing way too much Java lately, but I've gotten used to making my error messages verbose, at least in the development and testing phases. The first thing I thought when I read

error creating \\NTSERVER\TempLogs\020910145659! at testWL.pl line 28.
was "Great, but what was the error?" I heartily recommend outputting $! along with your tailor-made error messages, especially when making system calls:
system(@args) == 0 or die "error creating $createDir :\n$!";
This will tend to send whatever error the system call farted out into the error Perl dies with.


LAI
:eof

Replies are listed 'Best First'.
Re: Re: Moving Log files remotely
by dantie (Initiate) on Sep 11, 2002 at 11:09 UTC
    True, true.

    $! is much more important than even the filename itself. For testing and debugging purposes I usually just do a 'or die $!', that gives me the linenumber and the problem, what, most times, is all I need..
    Allthough, sometimes it may be helpfull to write out the filname too, i.e. if you're not sure whether it is correct (calculated).

    lg,
    daniel

      Quite right. I remember when I first started writing largeish projects, and was using some OOness that got pretty convoluted at times. Often, when Perl died it spat out a filename and line number that was completely useless. It would be the file that was calling a function in another file that called a function in another file where there was a bug. I quickly learned to output readable and informative debug messages.

      Actually, AFAIR (and my memory is patchy at best) if there's a bug inside an eval statement, don't the dying words say that the problem was on line 0 or something... or just not complain at all...

      Anyway, now I have fun with error messages. Looking at debug output of my code you may see stuff like the following:

      The Command Dispatcher hates you beause: java.lang.NullPointerExceptio +n The GUI farted the following: ArrayOutOfBoundsException: 3 >= 1
      or whatever. Like I said, way too much Java lately :o)


      LAI
      :eof
      Hmmm. I would say both $! and the filename are very important to include in the error message, if only because malforming the filename in some way is an extremely common problem and can occur in many ways.

      What is especially insiduous and hard to track, is when a file exists with the malformed name. Now that is a real pain in the butt.

      Here are some common ways of malforming filenames:

      1 - path missing. This often occurs when using the result directly from readdir or File::Find::find without adding the path.

      2 - linebreak in filename. This typically occurs when newbies capture the output of `ls` or `dir` instead of using readdir as they should and forget to chomp.

      3 - Wrong case. Perl, like Unix, is case sensitive, but users raised on Windows and Mac systems tend to forget this.

      4 - Concatenating a file name in the wrong way, for example:

      my $path = '/usr/home/jones'; my $file = 'foo.txt'; my $filename = $path . $file.
      This will result in the nonexistent filename /usr/home/jonesfoo.txt, but is hard to catch.

      5 - Using unescaped backslashes on Windows (extremely common). Filenames like "C:\terry\new.html" are a common source of Windows/Perl nightmares (Perl reads it as "C: TAB erry NEWLINE ew.html"). Use ordinary slashes under Windows and save yourself endless hassle as well as making your code more portable as a side effect.

      I hope this helps someone.

      Regards,
      Helgi Briem