Python: Returning errors rather than throwing

Question

Here is the normal way of catching and throwing exceptions to callee's

def check(a):

    data  = {}

    if not a:
        raise Exception("'a' was bad")

    return data

def doSomething():

    try:
        data = check(None)
    except Exception, e:
        print e

Here is an alternative + a few things I like:

'data' is always present, the 'check' function could set up some defaults for data, the logic is then contained within the function and doesn't have to be repeated. Also means that a dev can't make the mistake of trying to access data when an exception has occurred. (data could be defined at the very top of 'doSomething' function + assigned some defaults)

You don't have to have try/excepts everywhere cluttering up the 'doSomething' functions

def check(a):

    errors = []
    data = {}

    if not a:
        errors.append("'a' was bad")

    return data, errors

def doSomething():

    data, errors = check(None)
    if errors:
        print errors

Is there anything wrong with it? what are people's opinions?

BrenBarn · Accepted Answer · 2013-07-13 23:46:14Z

4

There are times when the second approach can be useful (for instance, if you're doing a sequence of relatively independent operations and just want to keep a record of which ones failed). But if your goal is to prevent continuing in an incorrect state (i.e., not "make the mistake of trying to access data when an exception has occurred"), the second way is not good. If you need to do the check at all, you probably want to do it like this:

def check(a):
    data  = {}
    if not a:
        raise Exception("'a' was bad")
    return data

def doSomething():
    data = check(None)
    # continue using  data

That is, do the check and, if it succeeds, just keep going. You don't need to "clutter up" the code with except. You should only use try/except if you can actually handle the error in some way. If you can't, then you want the exception to continue to propagate, and if necessary, propagate all the way up and stop the program, because that will stop you from going on to use data in an invalid way.

Moreover, if it's possible to continue after the check but still "make the mistake" of accessing invalid data, then you didn't do a very good check. The point of the check, if there is one, should be to ensure that you can confidently proceed as long as the check doesn't raise an exception. The way you're doing it, you basically do the check twice: you run check, and then you check for an exception. Instead, just run the check. If it fails, raise an exception. If it succeeds, go on with your code. If you want the check to distinguish recoverable and unrecoverable errors and log the unrecoverable ones, then just do the logging in the check.

Of course, in many cases you can make it even simpler:

def doSomething():
    data.blah()
    # use data however you're going to use it

In other words, just do what you're going to do. You will then get an exception if you do something with data that doesn't work. There's often no reason to put in a separate explicit check. (There are certainly valid reasons for checks, of course. One would be if the actual operation is expensive and might fail at a late stage, so you want to check for validity upfront to avoid wasting time on an operation that will fail after a long computation. Another reason might be if the operation involves I/O or concurrency of some kind and could leave some shared resource in an invalid state.)

edited Jul 13, 2013 at 23:46

answered Jul 13, 2013 at 23:34

BrenBarn

253k39 gold badges421 silver badges392 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

user1669710 Over a year ago

you can still raise an exception, catch it and print an error message or log the error - without having to stop program execution at that point; exceptions increase code readability by alerting the reader what errors may happen with that piece of code.

BrenBarn Over a year ago

@user1669710: You can, but not if you care about continuing with invalid data. Also, if you know at the time the exception is raised that it's not really a big deal, you should just use a warning instead.

martineau Over a year ago

It sometimes useful to put one try/except around a long suite of statements -- even most of the script -- in order to do clean-up if anything goes wrong during the process. This allows the process to fail "gracefully" and terminate leaving things in the best state possible.

santosh.ankr · Accepted Answer · 2013-07-13 23:28:07Z

1

Some years from now, when you read your own code again and try to figure out what on earth you were trying to do, you'll be glad for all the clutter of the try-excepts that help make perfectly obvious what is an error and what is data.

answered Jul 13, 2013 at 23:28

santosh.ankr

6714 silver badges12 bronze badges

Comments

user1669710 · Accepted Answer · 2013-07-13 23:38:13Z

1

try/excepts are not clutter; They increase the code readability by indicating that this piece of code can "expect" an exception. If you mix your logic-"ifs" with error-handling "ifs" - you may lose some readability in your code.

Further, if you know 'a' being None is the only kind of error you will have, you can write an if and handle it this way; Makes sense in this simple example you gave.

However, if a different error happens, an exception is raised anyway!

I wouldn't recommend to use it as a general programming practice to avoid try/except anywhere. It is acknowledging and marking places in code where exceptions happen.

answered Jul 13, 2013 at 23:38

user1669710

2341 silver badge11 bronze badges

Collectives™ on Stack Overflow

Python: Returning errors rather than throwing

3 Answers 3

3 Comments

Comments

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

3 Comments

Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Related