exception
¶
OVERLAY_SOURCE_TO_YAML_SOURCE = {'design': 'design_yaml_file', 'locale': 'locale_yaml_file', 'settings': 'settings_yaml_file'}
module-attribute
¶
OverlaySourceKey = Literal['design', 'locale', 'settings']
¶
YamlLocation = tuple[tuple[int, int], tuple[int, int]]
¶
YamlSource = Literal['main_yaml_file', 'design_yaml_file', 'locale_yaml_file', 'settings_yaml_file']
¶
RenderCVInternalError(message)
dataclass
¶
Bases: RuntimeError
Internal error indicating a bug in RenderCV logic.
Why
Distinguishes programmer errors (unreachable states, broken invariants) from user errors. These should never reach end users in normal operation and indicate code that needs fixing.
message
instance-attribute
¶
RenderCVUserError(message=None)
dataclass
¶
Bases: ValueError
User-facing error for recoverable problems like invalid input or missing files.
Why
CLI commands catch this to display clean error panels without stack traces. Separating user errors from internal errors ensures only actionable messages reach end users.
message = field(default=None)
class-attribute
instance-attribute
¶
RenderCVUserValidationError(validation_errors)
dataclass
¶
Bases: ValueError
User-facing error carrying multiple structured validation errors.
Why
YAML validation can produce many errors at once. Aggregating them in a single exception enables the CLI to display all problems in one pass rather than stopping at the first.
validation_errors
instance-attribute
¶
RenderCVValidationError(schema_location, yaml_location, yaml_source, message, input)
dataclass
¶
Structured validation error with YAML source location for error reporting.
Why
Pydantic errors lack YAML file position info. This bridges the gap by pairing schema-level error details with YAML line/column positions so the CLI can display precise, user-friendly error locations.