Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re^3: improve ugly flow control

by Aristotle (Chancellor)
on Sep 26, 2004 at 11:36 UTC ( #393924=note: print w/replies, xml ) Need Help??

in reply to Re^2: improve ugly flow control
in thread improve ugly flow control

How so? You've basically turned my TRY block into a function and deferred the failure handling through an exception. That doesn't seem more efficient to me — am I missing something?

I don't particularly like exceptions as a mechanism to deal with soft failures though. In case I did need to handle multiple cases, I'd do something much along the lines of my first post, like this:

OPTION_LIST: for( [ \%hash1, \@options1, \&do_something1, ], [ \%hash2, \@options2, \&do_something2, ], [ \%hash3, \@options3, \&do_something3, ], ) { my ( $hash, $options, $callback ) = @$_; foreach my $try ( @$options ) { next unless exists $hash->{ $try }; $callback->( $try ); next OPTION_LIST; } log_failure(); last; }

Note that both this and your code is deficient if you need atomic behaviour; do_something1 will already have been called by the time a failure to find any of the @options2 in %hash2 is detected. If that is undesired, a proper exception-based solution will hardly differ from the non-exception solution.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^4: improve ugly flow control
by dragonchild (Archbishop) on Sep 26, 2004 at 15:46 UTC
    My understanding of the OP's question was that this wasn't a "soft failure" situation. This was an out-and-out "Bad Thing"™ kind of failure. Exceptions aren't for everyone - this is true. However, a recommended method of working with DBI is to use RaiseError and eval/$@ blocks.

    The reason to defer to a function is that this method can now be used by multiple scripts / modules in multiple situations, providing the same handling in all installs for a given company. "Efficient" can mean multiple things. In my case, I look for efficiency in developer time. I am almost always less concerned with CPU/RAM efficiency1, because they almost always cost less than the equivalent developer time.

    1. Except, of course, in the pathological case where the tradeoff is grossly prejudiced against the hardware. It's a standard maximization problem that all first-year calculus students learn to solve.

    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://393924]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2018-04-19 16:16 GMT
Find Nodes?
    Voting Booth?