Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re7: Learning how to use the Error module by example

by dragonchild (Archbishop)
on Jul 30, 2003 at 13:30 UTC ( #279172=note: print w/ replies, xml ) Need Help??


in reply to Re^6: Learning how to use the Error module by example
in thread Learning how to use the Error module by example

My point is that if you're wrapping in a try-block, you should be throwing exceptions, even something like Error::OK or the like. In fact, I wouldn't even call them exceptions, really. They're more like signals within the same process. Just because we use them 99.999% of the time to indicate an abnormal situation doesn't mean that this is what they should be limited to ...

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.


Comment on Re7: Learning how to use the Error module by example
Re^8: Learning how to use the Error module by example
by adrianh (Chancellor) on Jul 30, 2003 at 13:50 UTC

    In the find() example, assuming that stored(), next() and first() can throw error exceptions, show me some simpler code using exceptions rather than multiple returns.

    I've no objection to using exceptions for non-error conditions. I do it all the time :-)

    However, I do have an objection to making my code more complex because of an arbitrary rule. Why should I not use return within a try block when it makes my code far easier to understand and maintain than the alternative? What is the downside?

      sub find { my ($self, $search_item) = @_; eval { # skip expensive search if item not stored anywhere throw Signal::Search::Not_Stored unless $search_item->stored; # otherwise do expensive search $self->first; while (my $item = $self->next) { throw Signal::Search::Found if $item == $search_item; }; throw Signal::Search::Not_Found; }; if ($@) { my $e = $@; # Do NOT handle Signals here. Those propagate back # up to the caller who will handle them appropriately. throw $e if $e->isa('Signal::Search'); ... handle exceptions here ... }; };
      I would argue that you have three possible return codes - NOT_STORED, FOUND, NOT_FOUND, plus all the possible exceptions that can occur. Instead of trying to shoehorn your return codes into a C-like morass of constants and bit-vectors, use signalling exceptions! Heck, you can even include a reference to the found item in your Signal::Search::Found object, if you were so inclined. And, your code is self-commenting because you make a distinction between NOT_STORED and NOT_FOUND, in case the caller or reader cares. If they don't, they can explicitly treat the two cases the same, increasing the commenting.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        But why is this better than the version using return? (and we don't care between no-stored and not-found :-). Why are returns bad?

        We just seem to be adding three more exception classes, moving the logic of what we care and don't care about handling from the mainline to the catch block, and making the caller handle exceptions when they're just interested in a boolean value. How is this simpler? All the callers of find are now going to have to do:

        eval { $self->find($foo) }; print "found" if ( UNIVERSAL::isa($@, 'Signal::Search::Found') ); die $@ unless UNIVERSAL::isa($@, 'Signal::Search'); # rather than print "found" if $self->find($foo);

        which seems insane - but ignoring that point what is wrong with the return? That's the bit I'm not getting.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://279172]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (11)
As of 2014-04-18 12:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (466 votes), past polls