in reply to Tracking down errors in data from input files.

$. is a global variable, so if you're always working with the current line, you don't need to pass it around.

For debugging I always use Carp::confess (it's in core) instead of die, which gives me a full stack trace.

If you want to associate additional informations (like line numbers) with your data, I recommend the object oriented approach.

Replies are listed 'Best First'.
Re^2: Tracking down errors in data from input files.
by why_bird (Pilgrim) on Mar 07, 2008 at 11:20 UTC
    Thankyou both, I'll look into Carp (and thanks for the tip about push (@array) --- I didn't realise it made a difference, d'oh!)
    moritz, humour me? :) where would I start with an object oriented approach in Perl? How would this help me track down line number etc?
    Cheers, why bird
    ........
    Those are my principles. If you don't like them I have others.
    -- Groucho Marx
    .......
[reply]
      Object Orientation in Perl

      My idea was inspired by compilers. They usually build a parse tree where the nodes store the matched text, logical information (what kind of token is this?) and the position in the source file.

      Now if that parse tree is converted to an abstrac syntax tree, they still keep that line information, so if there is an execution error (let's say division by zero) the compiler can tell you which line of code caused that error.

      So you can create a class "Traceable" that stores a string and its position in an input file to keep track of where it comes from.

      It might be a bit overkill in your project, but for larger projects (parser, compiler) that is common practice.

      (BTW it's nice to see that the quality of your questions improve over time ;)

[reply]

        Thanks moritz---I think I got (some of) that, I don't think I can justify doing this for my current work project. (which doesn't neccessarily mean I won't try to do it anyway :) ). I might try it at home when I get some time, but think I have a way to go with OO before attempting something like that..

        But if the compiler knows what calls what and from where (since it prints that kind of stuff in error messages) is there a way to hi-jack that information?

        Also.. did you mean my questions were getting clearer or less stupid? :P

        Cheers why_bird
        ........
        Those are my principles. If you don't like them I have others.
        -- Groucho Marx
        .......
[reply]

In Section Seekers of Perl Wisdom