Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: Best practices for handling errors

by sundialsvc4 (Abbot)
on Sep 29, 2014 at 02:28 UTC ( [id://1102311]=note: print w/replies, xml ) Need Help??


in reply to Best practices for handling errors

There are many different opinions on this.   In Python circles, for example, there’s a truism that “it’s easier to ask forgiveness than permission,” so a widely accepted practice is to “just do it,” relying upon an exception (of a particular class) being thrown if it turns out that you can’t.   Exceptions are thrown in all sorts of benign circumstances, including “to end an iterator-loop.”   Ordinarily, code which uses the try..except..finally constructs check for a particular exception-class or classes, intercepting only those that are expected.   (As expected, exceptions which are never caught by anyone typically kill the program.)

And it turns out that Perl can do this, too.   The die() function can accept any object, not just a string, and there are several “exception class hierarchy” packages available to exploit this capability.

As it happens, I find myself using “classed exceptions” frequently, throwing exceptions in basically all of the situations where I might previously have used “a non-zero return code,” but also for benign purposes.   It’s much too late to change the name of Perl’s die() function, as if we ever would want to, but it is a bit misleading.   You are raising, or “throwing,” an exception ... which may or may not be “a bad thing.”

Log In?
Username:
Password:

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

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

    No recent polls found