in reply to Re^2: eval to replace die?
in thread eval to replace die?

The source of errors isn't always within the script - the "open or die" idiom is used extensively in the documentation, the Camel book etc - for quick scripts, to say, parse a system file and print some useful info, this construct is perfectly suitable - exception handling etc has its place, agreed - but it's a judgement call where that place is.

Replies are listed 'Best First'.
Re^4: eval to replace die?
by chromatic (Archbishop) on Oct 04, 2010 at 14:43 UTC

    I agree that it's difficult to use exception objects pervasively (especially when using other code), and I wouldn't have enabled this rule for Perl::Critic by default myself, but it's very much worth considering the risk and fragility of string comparisons for exception handling.

[reply]
      the risk and fragility of string comparisons for exception handling.

      Even in Java, it's still "string compare". It's done at compile-time rather than run-time, which is good. But it is still string compare.

      But Exception::Class does not give you that advantage.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        I should be more precise, you're right.

        Imagine instead I wrote "the risk and fragility of using fuzzy regular expression matches for exception handling, especially when type checks and polymorphism are much more reliable".

[reply]
Re^4: eval to replace die?
by mjscott2702 (Pilgrim) on Oct 05, 2010 at 08:33 UTC
    Wow, I opened up a whole can of worms there. What I was trying to point out was simply this - sometimes, it doesn't matter WHY something went wrong, just to die gracefully with some informative message e.g. File Not Found.

    In the case of a simple script that is trying to parse a file that it can't access (permissions, missing file etc), there is nothing to recover from - give the user some clue as to what went wrong, and terminate.

    Obviously, there are situations where the script/application/program shouldn't exit - trap the error, display the error message, log it and continue.

    The use of eval, catching exceptions, trapping signals etc is the choice of the programmer - TMTOWTDI.

    And yes, that might mean some fuzzy string comparisons.... :)

[reply]

In Section Seekers of Perl Wisdom