Skip to content

API reference · 08 of 8

Errors

The exceptions Cuprum raises when a program is unknown, forbidden, or too slow, when a stdin producer fails, or when a signal cannot reach a child.

Read from Cuprum 0.2.0-beta2 at a4089878

exception

ForbiddenProgramError

cuprum/context/_scope.py, the source of ForbiddenProgramError
class ForbiddenProgramError(
    program: Program,
    *,
    restricted_state: bool,
) -> None

Bases: ContextError, PermissionError

Raised when attempting to run a program not in the current allowlist.

Attributes

program Program
The program that was denied by the context allowlist.
restricted_state bool
Whether the context allowlist was in a restricted state when the program was denied.
exception

TimeoutExpired

cuprum/sh/execution.py, the source of TimeoutExpired
class TimeoutExpired(
    *,
    cmd: cabc.Sequence[str] | object,
    timeout: float,
    output: str | bytes | None = None,
    stderr: str | bytes | None = None,
) -> None

Bases: TimeoutError

Raised when command execution exceeds the configured timeout.

1 member

property TimeoutExpired.stdout

stdout: str | bytes | None

Captured stdout, mirroring subprocess.TimeoutExpired.

Returns
str | bytes | None
Captured standard output, or None when no output was captured before expiry.
exception

StdinSourceError

cuprum/sh/execution.py, the source of StdinSourceError
StdinSourceError

Bases: Exception

Raised when a streaming stdin producer or its encoder fails.

A caller who supplies a StdinStream sees failures from three sources wrapped in this type: the producer raising while being pulled, the producer yielding a value that is neither str nor bytes, and the incremental encoder rejecting a str chunk. The original exception is chained as __cause__, so the caller can still inspect it.

The child is terminated before this is raised, and the run's stdin writer and pipe are finalized, so catching this type is enough to know that no writer outlives the run. Cancellation is *not* wrapped: an asyncio.CancelledError propagates unchanged, because it is a control-flow signal rather than a source failure.

exception

SignalAfterExitError

cuprum/_process_handle_errors.py, the source of SignalAfterExitError
class SignalAfterExitError(
    exit_code: int,
    pid: int | None = None,
) -> None

Bases: ProcessLookupError

Raised when a signal is requested for a child that has already exited.

A caller coordinating several signals cannot avoid racing the child's own exit, so this is an ordinary outcome rather than a misuse: the handle reports it with the exit code it recorded, letting the caller decide whether the command's ending already satisfies them.

Subclasses ProcessLookupError because that is exactly what the operating system reports once the child is gone, and a caller that already tolerates a lost process keeps working when the handle names the condition.

Attributes

exit_code int
The code the handle recorded for the child, which is the signal number negated when a signal ended it.
pid int | None
The child's process identifier, or None when asyncio never reported one.
exception

UnsupportedSignalError

cuprum/_process_handle_errors.py, the source of UnsupportedSignalError
class UnsupportedSignalError(
    signal_number: int,
    platform_name: str,
) -> None

Bases: RuntimeError

Raised when the platform cannot deliver a caller-named signal.

Distinct from SignalAfterExitError because the remedy differs: no retry can help here, and a caller that needs to stop a child on such a platform has to reach for the handle's terminate or kill operations, which use the platform's own signals.

Attributes

signal_number int
The signal the caller asked to deliver.
platform_name str
The platform that declined it, as sys.platform spells it.