CODEWITHSUNDEEP
pythonpython-asyncio
VPfB
VPfB

Reputation: 17237

Why asyncio raises TimeoutError without any message?

I encountered a small annoyance with this code:

try:
    return await asyncio.wait_for(tcp_command(cmd), timeout=timeout)
except (OSError, asyncio.TimeoutError) as err:
    print(f"Network problem: {err}")

When the timeout occurs, it prints just "Network problem: ". It is caused by an empty value attached to the raised asyncio.TimeoutError:

# inside wait_for():
raise futures.TimeoutError()

It is easy to hadle the TimeoutError separately, but I find the original construct quite idiomatic and now a core library breaks it. Is there a good reason for it? Is my assumption - that printing an exception should give us a clue what went wrong - correct?

Upvotes: 1

Views: 1085

Answers (2)

user4815162342
user4815162342

Reputation: 154836

The expectation that an exception will provide a message that explains the issue is not part of the general exception contract in Python. It is true for system exceptions such as OSError where the program must be able to get to the error message provided by the operating system, as the program is not qualified to guess the message based on a code or an exception subtype.

But more basic language exceptions do not work like that. Take, for example, KeyError raised by dict.__getitem__:

>>> try:
...   d[123]
... except KeyError as err:
...   print(f"Dict problem: {err}")
... 
Dict problem: 123

In this sense, TimeoutError is much more like KeyError than like OSError. When you catch TimeoutError, you know exactly what happened - a timeout. You typically want to do something based on the fact that a timeout happened, rather than just display a message to the user. And even if you did want to provide a message, you'd use one that would make sense for your application, not a generic one provided by Python. This is in contrast to OSError where you often cannot do anything other than display the message coming from the OS and where that message can prove invaluable for investigating the underlying issue.

To sum it up, the problem is that you are catching two fundamentally different exceptions in the same except clause, and that set you up for trouble. I would restructure the code like this:

try:
    return await asyncio.wait_for(tcp_command(cmd), timeout=timeout)
except OSError as err:
    print(f"Network problem: {err}")
except asyncio.TimeoutError:
    print("Operation timed out")

Upvotes: 2

freakish
freakish

Reputation: 56467

Is there a good reason for it?

Yes, what kind of message you expect from TimeoutError? "Timeout occured"? The exception itself is self-explanatory, no need for such redundancy.

Is my assumption - that printing an exception should give us a clue what went wrong - correct?

Yes and no. Clue? Yes. Full information? No. The exception message is not mandatory. And the type of an exception is an important piece of information as well. And in many cases even more then the message itself.

So first of all: using print is wrong to begin with. Python has a very rich logging support. For example logger.exception(str(exc)) solves your problem because it logs entire traceback in addition to the message. At least by default, it can be customized.

But if you still want to use print then consider logging whole traceback:

import traceback
# traceback.print_exc()
print(traceback.format_exc())

If whole traceback is too big then you can always simply print the exception's class name:

# print(f'[{type(exc).__name__}] {exc}')
print(f'[{type(exc)}] {exc}')

or customize by exception:

try:
    return await asyncio.wait_for(tcp_command(cmd), timeout=timeout)
except OSError as err:
    print(f"Network problem: {err}")
except asyncio.TimeoutError:
    print('Timeout occured')

Upvotes: 3

Related Questions