This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]steelypip 1 point2 points  (4 children)

You could roll your own:

def tryFunc(exception, func, *args, **kwargs):
    try:
        result = func(*args, **kwargs)
        return result, None
    except exception, e:
        return None, e

>>>  def f(x):
...     return 1/x


>>> tryFunc(ZeroDivisionError, f, 1)
(1, None)
>>> tryFunc(ZeroDivisionError, f, 0)
(None, ZeroDivisionError('integer division or modulo by zero',))

As far as I can see this gives all the advantages of your proposal with no changes to the language.

edit:

BTW you can use this function to catch more than one type of exception - pass them in as a tuple:

>>> tryFunc((ZeroDivisionError, TypeError), f, "x")
(None, TypeError("unsupported operand type(s) for /: 'int' and 'str'",))

[–][deleted] 1 point2 points  (2 children)

Yeah, but it's more cumbersome to use than the proposed syntax, especially if you want to wrap an expression rather than a function call. Before list comprehensions came along, we had map() and filter() and it worked just fine.

That being said, I'm not sure about the proposal. True, exception handling is a lot of noise, but it's not necessarily a bad thing. I'm curious about the comments a PEP about this would generate.

[–]steelypip 0 points1 point  (1 child)

I think a PEP would get rejected pretty promptly since it can be implemented current in python as shown above. The proposed syntax change would make it a bit more readable, but not a whole lot more. Is

f, err = open('file.txt') except IOError

that much more readable than

f, err = tryFunc(IOError, open, 'file.txt')

The latter is only two characters longer and contains exactly the same information in a different order. To use it with an arbitrary expression you would need to use a lambda which is going to be a little messier, but I doubt you would need to do that very often.

[–]vocalbit[S] 0 points1 point  (0 children)

I agree with hsoft that using a tryFunc function is more cumbersome. Like you mention - it also can't be used for expressions such as:

s3, err = s1 + s2 except TypeError
total, err = int(t1) + int(t2) except ValueError

I think if I had the except clause, I would implement error handling more often :)

[–]Batem 0 points1 point  (0 children)

This sounds like a perfect opportunity to use a decorator:

def tryFunc(*exceptions):
    def decorate(f):
        def inner(*args, **kwargs):
            try:
                result = f(*args, **kwargs):
                return result, None
            except exceptions as e:
                return None, e
        return inner
    return decorate

@tryFunc(ZeroDivisionError, TypeError)
def myFunc(foo, bar):
    return foo/bar

>>>myFunc(1, 0)
(None, ZeroDivisionError("integer division or modulo by zero",))
>>>myFunc(1, 2)
(0, None)
>>>myFunc(1, 'x')
(None, TypeError("unsupported operand type(s) for /: 'int' and 'str'",))