Re: Re: return eval { die() } idiom

thanks, but that I understand:

   eval {
      # blah blah...
      die ("fooblah");
      # or
      something_that_may_die();
   };
   if($@) { 
      # do something
    }
[download]

That's how I would normally use it.

I'm talking about this: "return eval { BLOCK }", where BLOCK is the main block of your code...

Comment on Re: Re: return eval { die() } idiom Download Code

Replies are listed 'Best First'.
Re: Re: Re: return eval { die() } idiom by monsieur_champs (Curate) on Aug 29, 2003 at 21:05 UTC
Dear lestrrat AFAIK, the only difference between tfc22's code and yours is the way you handle errors. In essense, both codes do the same thing. I really see no point about where you `die()` for errors, since you `die()` for errors somewhere in your code. What I see is `Just Another Way To Do It`. Maybe some benchmarking could reveal something more interesting. On the other hand, as you mentioned before, the guys who coded the initial snippet use to code C, and the idiom is much more readable to C programmers than it is for smalltalk-based perl programmers (like me). Maybe this is the advantage you're looking for: C programmers that see this kind of construction will more likely recognise it (and feel at home) than programmers with other backgrounds. My two pence. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= monsieur_champs	[reply] [d/l] [select]
Re: Re: Re: return eval { die() } idiom by tcf22 (Priest) on Aug 29, 2003 at 19:54 UTC
I personally don't really like that construct, but I have seen it used. I really think that it is just a matter of preference. Using the return eval construct, makes you function behave more like a built-in function, returning a status and setting an error variable($@) if needed. This can be done many other ways as I'm sure you are aware(TIMTOWTDI). I haven't ran `Benchmark`, so I'm not sure, but this seems like it would be slower than just checking the return status, setting an error variable, then `return`ing.	[reply] [d/l] [select]