in reply to Re: testing a croak
in thread testing a croak

A i see what you mean now by 'testing a croak without die'.
BrowserUk is right, but i do not like it, for 2 reasons.

1. I don't like eval.
Eval creates major security issues if improper used. (and that happens fast). But you're using it for testing, so that won't probably stop you here.
2. I don't like die
A script that dies with an error is not my kind of taste. I'd better like to use carp or cluck, and give a warning to the user, but definately not die. (Especially for webbased applications, where they give nasty server-errors)

*Update* I really don't understand the 'big' discussion that comes up now. I never stated that i BrowserUk was wrong, i said he is right.
I only stated that i (me myself and i), don't like it, that is not stating that i never use it, or that it should not be used at all.
I gave 2 reasons (you can agree with or not) why, and IMHO, correct reasons.
I mainly work in web applications, most of the time a simple warn is enough to create the proper logs i need.
Next, the use of eval can be dangerous, that's what i point out, not that it allways is, and yes i use eval as well.

Next, i NEVER EVER stated that my programs are perfect (in fact, they're far from perfect, like most programs are).

I've got a slight feeling here that there is a bit overreacting here on something that was stated as my own opinion.
"We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." - Larry Wall.

Replies are listed 'Best First'.
Re^3: testing a croak
by BrowserUk (Pope) on Jan 19, 2006 at 06:12 UTC
    Eval creates major security issues if improper used.

    Wrong. That problem only exists with the string form of eval, not the block form shown, which is the standard Perl equivalent of the try()/catch() pairing found in other languages. Ie. it is the proper way to do this.

    2. I don't like die

    Your prerogative, but it is a standard language facility and deciding you don't like it is arbitrary. Also, remember that not all Perl programs are "web applications".


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Wrong. That problem only exists with the string form of eval, not the block form shown, which is the standard Perl equivalent of the try()/catch() pairing found in other languages. Ie. it is the proper way to do this.

      I know you're using it the proper way, but i only state to be careful with it and that you absolutely should know what you're doing, (As stated if improper used.. Thats why i try to avoid the usage of it, a mistake is easily made like this:
      #!/usr/bin/perl -w use stritct; my $c1 = 'system("touch /tmp/test1.txt")'; my $c2 = 'system("touch /tmp/test2.txt")'; #used as string (Dangerous!!!) eval $c1; #used as block (ok) eval {$c2}; # <- gives a useless use of private variable in void cont +ext.
      .
      "We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." - Larry Wall.
        You can think of the two versions of eval as completely different 'functions' (although the block form is not a function - it's a flow control statement(?)). Perhaps they should actually have different names, because they do completely different things.

        String eval takes a string, interpolates varibles, and executes the string as Perl code. You use this to delay the evaluation / parsing of whatevers in the string to run-time. It allows you to build Perl programs on the fly and run them. The reason it's dangerous is because the temptation is there to insert user input into the string, effectively allowing the user to execute arbitrary code.

        Block eval doesn't have this issue because the code inside it is parsed at the same time as the rest of the code in the program. Therefore, user values can't be inserted into the code.

        The primary use of block eval is to catch die / croak, etc. Again, this is another slightly strange naming issue in Perl - in this case, your program won't actually die, it just provides a way of exception handling (i.e. passing error information between levels of the application). In most other languages, the block eval is called 'try', and has a corresponding block called 'catch'. In Perl (5 at least, this changes in 6), the same functionality is achieved by eval{} / if ($@).

        I suggest you read the eval POD for full details.
Re^3: testing a croak
by blazar (Canon) on Jan 19, 2006 at 09:45 UTC
    I don't like die

    /me too. In fact my programs are perfect and never die. Being such a perfect programmer, not only the OS and environment and filesystem they run on are also perfect and never cause failures, etc. but even the users of my programs are perfect (the most prominent one being myself - so that's already a guaranteee!) and never make errors like supplying inexistent files, etc.

    Seriously, web development is not the whole world. die is a perfectly valid and handy language feature - indeed for complex applications, possibly running a GUI, it is sensible to adopt other ways round other than dieing, like warning the user and asking for more input. But for a script that expects a filename on the cmd line to parse, I can't see a more intelligent option than to die, if the file does not exist, for example.