异常和警告

Exceptions and warnings

exception trio.Cancelled(*args: object, **kwargs: object)

基类：BaseException

Raised by blocking calls if the surrounding scope has been cancelled.

You should let this exception propagate, to be caught by the relevant cancel scope. To remind you of this, it inherits from BaseException instead of Exception, just like KeyboardInterrupt and SystemExit do. This means that if you write something like:

try:
    ...
except Exception:
    ...

then this won't catch a Cancelled exception.

You cannot raise Cancelled yourself. Attempting to do so will produce a TypeError. Use cancel_scope.cancel() instead.

备注

In the US it's also common to see this word spelled "canceled", with only one "l". This is a recent and US-specific innovation, and even in the US both forms are still commonly used. So for consistency with the rest of the world and with "cancellation" (which always has two "l"s), Trio uses the two "l" spelling everywhere.

exception trio.TooSlowError

基类：Exception

Raised by fail_after() and fail_at() if the timeout expires.

exception trio.WouldBlock

基类：Exception

Raised by X_nowait functions if X would block.

exception trio.EndOfChannel

基类：Exception

Raised when trying to receive from a trio.abc.ReceiveChannel that has no more data to receive.

This is analogous to an "end-of-file" condition, but for channels.

exception trio.BusyResourceError

基类：Exception

Raised when a task attempts to use a resource that some other task is already using, and this would lead to bugs and nonsense.

For example, if two tasks try to send data through the same socket at the same time, Trio will raise BusyResourceError instead of letting the data get scrambled.

exception trio.ClosedResourceError

基类：Exception

Raised when attempting to use a resource after it has been closed.

Note that "closed" here means that your code closed the resource, generally by calling a method with a name like close or aclose, or by exiting a context manager. If a problem arises elsewhere – for example, because of a network failure, or because a remote peer closed their end of a connection – then that should be indicated by a different exception class, like BrokenResourceError or an OSError subclass.

exception trio.BrokenResourceError

基类：Exception

Raised when an attempt to use a resource fails due to external circumstances.

For example, you might get this if you try to send data on a stream where the remote side has already closed the connection.

You don't get this error if you closed the resource – in that case you get ClosedResourceError.

This exception's __cause__ attribute will often contain more information about the underlying error.

exception trio.RunFinishedError

基类：RuntimeError

Raised by trio.from_thread.run and similar functions if the corresponding call to trio.run() has already finished.

exception trio.TrioInternalError

基类：Exception

Raised by run() if we encounter a bug in Trio, or (possibly) a misuse of one of the low-level trio.lowlevel APIs.

This should never happen! If you get this error, please file a bug.

Unfortunately, if you get this error it also means that all bets are off – Trio doesn't know what is going on and its normal invariants may be void. (For example, we might have "lost track" of a task. Or lost track of all tasks.) Again, though, this shouldn't happen.

exception trio.TrioDeprecationWarning

基类：FutureWarning

Warning emitted if you use deprecated Trio functionality.

As a young project, Trio is currently quite aggressive about deprecating and/or removing functionality that we realize was a bad idea. If you use Trio, you should subscribe to issue #1 to get information about upcoming deprecations and other backwards compatibility breaking changes.

Despite the name, this class currently inherits from FutureWarning, not DeprecationWarning, because while we're in young-and-aggressive mode we want these warnings to be visible by default. You can hide them by installing a filter or with the -W switch: see the warnings documentation for details.