stepup.core.exceptions
Exceptions used in StepUp.
AmendWhileHoldingError
¶
Bases: GraphError
amend(inp=...) was called while the calling step has an open hold() block.
CgroupError
¶
ConfigError
¶
Bases: UsageError, ValueError
A configuration file or environment variable holds something StepUp cannot use.
ValueError is kept in the bases because most of the underlying problems
(bad TOML syntax, a value of the wrong type, a value outside the allowed choices)
surface as a ValueError before being wrapped in this class.
The raise site says nothing a user could act on: the message names the config file or environment variable to fix.
Source code in stepup/core/exceptions.py
ConsistencyError
¶
Bases: RuntimeError
An invariant of the workflow graph is violated.
Deliberately not a UsageError:
no plan can put the graph in such a state through the public API,
so this always points at a bug in StepUp
(or at a database corrupted by something outside it),
and the full traceback is what a bug report needs.
Source code in stepup/core/exceptions.py
CyclicError
¶
Bases: GraphError
Adding a new relation would introduce a cyclic dependency.
EnvVarError
¶
Bases: StepUpError
An environment variable referenced in a path or string could not be resolved.
GraphError
¶
Bases: UsageError
A change to the graph could not be made as it would introduce an inconsistency.
HashCancelledError
¶
HashError
¶
HashFailedError
¶
InputNotFoundError
¶
PathError
¶
Bases: StepUpError
A path argument is invalid.
Raised when a path does not exist, has the wrong type
(e.g. a directory where a file is required),
or violates the leading ./ / trailing / affix contract.
RPCClientUnusableError
¶
Bases: ConnectionResetError
An RPC client was used after it stopped being able to talk to the server.
The client was closed, or an interrupted exchange left it out of step with the server.
Neither is a reset by the peer, which is what makes this worth telling apart,
but ConnectionResetError is kept in the bases
so that code catching a lost connection keeps catching this too.
Source code in stepup/core/exceptions.py
RPCError
¶
RunError
¶
StepUpError
¶
Bases: UsageError, ValueError
Invalid argument passed to a StepUp user- or extension-facing API function.
ValueError is kept in the bases so that existing except ValueError code
keeps catching these errors.
ToolError
¶
Bases: UsageError
An error raised by a stepup subcommand, i.e. by a tool.
This is what a tool raises for a situation that the user is expected to run into, such as a command that needs a workflow database in a directory that has none.
Source code in stepup/core/exceptions.py
UsageError
¶
Bases: Exception
Base class for errors that the user can fix by changing their own code.
These are reported as a short message without a traceback, unless STEPUP_DEBUG is set:
a step or a stepup subcommand that raises one ends with return code 1,
and the director sends one to the client without a director-side traceback.
Any other exception keeps the full traceback,
because it indicates a bug in StepUp rather than in the user’s plan.