in reply to Perl etiquette - eval

Nothing particularly wrong with that. One Big Eval for the entire program isn't part of my personal style, but I suppose it's sensible as long as there are little evals burried within for more specific errors. Any performance loss should be minimal, unless there is an eval inside a critical loop. The only particular issue I can think of is that evals sometimes do funny things to stacktraces, so debugging might be harder.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: Perl etiquette - eval
by waswas-fng (Curate) on Jan 18, 2004 at 00:04 UTC
    Sometimes it does make sense when the whole block is either pass or fail with no possibility of recovery. In this OP's instance the whole block of code that is used to reformat and repackage the mail may just have an acceptable level of "fail" status where the app says "ack, ok I do not know how to handle this mail for x reasons and it is acceptable to just pass the original message". Depending on what the requirements are for the app that seems like perfectly acceptable behavior -- recover and stay alive to process mail another day (CPU Cycle) =). I agree that in a whole lot of instances it is better to break down the eval try blocks to recoverable points in your code though.


    -Waswas
[reply]

In Section Seekers of Perl Wisdom