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

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.

  • Comment on Re^3: How do I replicate die's magic with $. ?

Replies are listed 'Best First'.
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]

      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]
      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]

In Section Seekers of Perl Wisdom