Python exception handling - How to do it pythonic?

Question 1

I am still learning the Python programmimg language. I asked myself in terms of code exceptions, when it is neccessary to handle such situations in a pythonic way. I read a few times "you should never pass an error silently".

For example a little function:

def square(list_with_items):    return [i**2 for i in list_with_items]

Is it neccessary to write an error-handler, if somebody passes a tuple as parameter?Or it is more senseful to do it, when I have to check the validation of user-input?

Question 2

You should catch the exception when you can handle the error. It's hard to say with your example. The question is, what would your handlerdo if you wrote one, versus writing it at a different place in the call chain?

Question 3

I think that what is meant by "passing an error silently" is to catch it, and not do anything useful with it (i.e. swallow it). If you don't catch it, it continues to the next level, and you can count on it not being "silent" -- someone will shout out.

Question 4

For example the routine of my program fails somewhere. Should I print a little error message, that something at this specific point went wrong. For debbuging is this helpful, but the finaöl user is more or less interested, that function xyz got a wrong parameter.

Question 5

Not really related to error handling, but in this example, the pythonic thing to do with atuple is to just handle it like you'd handle alist or generator input. Duck typing lets you do that.

Question 6

@shx2 Exactly that was my intention of this question.

Question 7

In the specific case of checking types, the "Pythonic" thing to do is not to check them. Unless there is a good reason, you should assume that the caller is passing in a sensible type (note: "sensible type" might be different from "the type you expect"), and do your best to return something sensible as well. If the caller passes in a type that isn't sensible, it's perfectly acceptable to let them deal with the consequences.

For example, someone might sensibly pass an iterator ofDecimal numbers into your square function:

>>> from decimal import Decimal>>> square(Decimal(line.strip()) for line in open("numbers.txt")[Decimal("4.0"), Decimal("9.0"), ...]

And everything would work! But explicitly checking the types would make that use case more difficult.

And then, for example, if someone passes in something that isn't sensible, they can deal with the error:

>>> square(42)…TypeError: 'int' object isn't iterable

This error message will also (in a script) contain all the file names and line numbers necessary to debug the issue.

On the other hand, it is sometimes useful to explicitly check the arguments, when the caller might make a mistake with surprising consequences. For example, if you're writing a function which will exhibit very poor performance with alist because it expects adeque, then a check forif not isinstance(input, deque): raise TypeError("a deque must be used!") might be justified.

The name for this "method for dealing with types" is calledDuck Typing.

Question 8

Great answer. I'll also add thislink to a related question about defensive programming versus exception handling in Python. See especially the answer about the Pythonic approach of Easier to Ask Forgiveness than Permission (i.e. don't check first, just do it and if needed catch exceptions in a limited way) as opposed to Look Before You Leap (checking things ahead of time, which may limit your options, e.g. forcing it to be a list of ints when it would have worked for other numeric types).

Question 9

Good answer, Python is dynamic, let it be unless there is a good reason you shouldn't, goes along with your "sensible type" statement.

Question 10

You could use an assertion:

def square(list_with_items):    assert(all([type(x) == int for x in list_with_items]))    return [i**2 for i in list_with_items]

You could use two assertions:

def square(list_with_items):    assert(type(list_with_items) in (list, tuple))    assert(all([type(x) == int for x in list_with_items]))    return [i**2 for i in list_with_items]

You could use an assertion and a try/catch:

def square(list_with_items):    assert(type(list_with_items) in (list, tuple))    try:        return [i**2 for i in list_with_items]    except TypeError:        raise Exception("Each element of the argument must be a number.")

Question 11

Useless typechecking is unpythonic, andassert is for debugging only.

Question 12

Thanks for your example. This is such an example I meant. For example my program should calculate a final result and the square-function is required internaly, as a step to get the result. Is this a good point to use a combination of assert and the catch-try-block, to output a context-specific warning? Good luck, if your program is a bit more complex.

Question 13

It depends. In that specific example, if you are going to use the return value of "square" in "read-only" manner, you shouldn't have a "real bug" passing a tuple as argument. That's because even if the tuple is immutable, your function will return a new tuple with the square of the elements of the first one.

Anyhow, I suggest you to use a simple if-else statement, to be more precise and to avoid issues (i.e.: if you are going to call this function in a different way in future):

def square(list_with_items):    if isinstance(list_with_items, list): # True if list_with_items is a list - False otherwise        return [i**2 for i in list_with_items]    else:        return 'Error: type(list_with_items) must be a list!'

EDIT: If you prefer (and if you are going to catch the exception with try-except statement), you could use "raise Exception" in the else-statement:

else:    raise Exception('Error: type(list_with_items) must be a list!')

Question 14

The thetuple may was not the best example, but what is, if my list contains a string instead of an integer. Which type the wrong object in this list has, doesn't matter. I only want to know, if it is senseful to output a little error-message, which contains the location of the error, or is that to much work?

Question 15

Python will output an error message for you in the form of a stack trace if you try to use a type that isn't sensible, and the stack trace will include all the line numbers you'll need to debug the issue.

Question 16

In that case, python will give you a TypeError: unsupported operand type(s) for ** or pow(): 'str' and 'int' (and so, probably the try-except statement can be necessary if is it possible that one of the element couldn't be a number). In general, is not mandatory to catch the exception. Take a look in example at your previous example (the tuple): your square function will work both with lists and tuples in "read-only". If your code could try to edit the return list/tuple, than the try-except could save your life. The little error-message (or a warning) can be very useful during the debug.

Question 17

Remember that the "little-error message" (generated with raise Exception) could be useful to catch that specific exception, to deal with it and to avoid crashes.

David Wolever 156k94 gold badges365 silver badges513 bronze badges · Accepted Answer · 2013-12-30 19:32:13Z

In the specific case of checking types, the "Pythonic" thing to do is not to check them. Unless there is a good reason, you should assume that the caller is passing in a sensible type (note: "sensible type" might be different from "the type you expect"), and do your best to return something sensible as well. If the caller passes in a type that isn't sensible, it's perfectly acceptable to let them deal with the consequences.

For example, someone might sensibly pass an iterator ofDecimal numbers into your square function:

>>> from decimal import Decimal>>> square(Decimal(line.strip()) for line in open("numbers.txt")[Decimal("4.0"), Decimal("9.0"), ...]

And everything would work! But explicitly checking the types would make that use case more difficult.

And then, for example, if someone passes in something that isn't sensible, they can deal with the error:

>>> square(42)…TypeError: 'int' object isn't iterable

This error message will also (in a script) contain all the file names and line numbers necessary to debug the issue.

On the other hand, it is sometimes useful to explicitly check the arguments, when the caller might make a mistake with surprising consequences. For example, if you're writing a function which will exhibit very poor performance with alist because it expects adeque, then a check forif not isinstance(input, deque): raise TypeError("a deque must be used!") might be justified.

The name for this "method for dealing with types" is calledDuck Typing.

Great answer. I'll also add thislink to a related question about defensive programming versus exception handling in Python. See especially the answer about the Pythonic approach of Easier to Ask Forgiveness than Permission (i.e. don't check first, just do it and if needed catch exceptions in a limited way) as opposed to Look Before You Leap (checking things ahead of time, which may limit your options, e.g. forcing it to be a list of ints when it would have worked for other numeric types).
Good answer, Python is dynamic, let it be unless there is a good reason you shouldn't, goes along with your "sensible type" statement.

Movatterモバイル変換

Collectives™ on Stack Overflow

Python exception handling - How to do it pythonic?

3 Answers3

2 Comments

2 Comments

4 Comments

Related

Hot Network Questions

Subscribe to RSS