Re^2: How do I replicate die's magic with $. ?

Thanks for the reply, but that doesn't answer my question. As I thought I was careful to explain, I know the error location, but I need to determine the name of the file handle associated with the value in $.. And as a library that doesn't do file IO, I have no clue what the file might be.

There's got to be a better way than:

my $msg = " at yourbadscript line your mistake";
if( defined $. ) {
    local $@ = '';
    eval {
            die;
    };
    if($@ =~ /^Died at .*(, <.*?> line \d+).$/ ) {
        $msg .= $1;
    }
}
$msg .= ".\n";
die $msg;
[download]

This communication may not represent my employer's views, if any, on the matters discussed.

Comment on Re^2: How do I replicate die's magic with $. ? Download Code

Replies are listed 'Best First'.
Re^3: How do I replicate die's magic with $. ? by chromatic (Archbishop) on Aug 06, 2011 at 17:50 UTC
And as a library that doesn't do file IO, I have no clue what the file might be. How do you know anything did IO then? When you can answer that question, you know the right place to handle the file/line information.	[reply]
Re^4: How do I replicate die's magic with $. ? by tlhackque (Beadle) on Aug 06, 2011 at 18:21 UTC
We aren't communicating. I'm in a library that has nothing to do with IO. I need to die gracefully and provide maximum help to my user. I don't know a priori about any IO done by my caller or her other libraries - but if $. is defined, someone, somewhere read or wrote a file. In that case, I want to provide the same information that die normally does, replacing die's call location with one more meaningful to the user. Users appreciate knowing that their problem manifested at record 5,916 of the file they know as <FROBULATOR> (or whatever). The code snippet that I provided above gets the answer. But it's a horrible way to get the answer. It requires an extra trapped exception, and parsing a text error message. The former is expensive, and the latter is not generally considered good practice for any number of reasons. So, If someone knows the answer to my question - how does one reliably and efficiently get the name of the file handle associated with $. - I'd appreciate an answer. Clearly, die figures it out - so it's available somewhere. This communication may not represent my employer's views, if any, on the matters discussed.	[reply]
Re^5: How do I replicate die's magic with $. ? by Corion (Patriarch) on Aug 06, 2011 at 18:26 UTC
If this is just for the error message, die (or Carp::croak, if deep in some library) will already inform your user of the relevant parts: `>perl -wle "open my $fh, 'makefile.pl'; <$fh>; die 'foo'" foo at -e line 1, <$fh> line 1.` [download] I'm not sure where outside of dieing the information can be helpful, and if you are dieing, why not use what Perl uses? Also, die usually is a one-time thing, so I wouldn't worry about the performance aspect of capturing an exception just to get at more information, if that really is necessary.	[reply] [d/l]
Re^5: How do I replicate die's magic with $. ? by JavaFan (Canon) on Aug 08, 2011 at 09:14 UTC
But it's a horrible way to get the answer. It requires an extra trapped exception, and parsing a text error message. The former is expensive, and the latter is not generally considered good practice for any number of reasons. It's expensive? Really? Considering the program is terminating (due to the die), which requires full garbage collection, calling DESTROY, etc, does one really care about an addition trapped exception? I presume you aren't going to die inside a tight loop. As the not considering good practice, is that really an issue? "Good practice" is subjective, and IMO, it isn't "good practice" to take "good practices" as dogma. It often doesn't hurt to be pragmatic. Clearly, die figures it out - so it's available somewhere. Yes. I advice you to study the `util.c` file that comes with the perl distribution. It may unlock `die`'s secrets.	[reply] [d/l] [select]