#[non_exhaustive]pub enum CoreError {
RecipeNotFound {
name: String,
},
Parse {
name: String,
diagnostics: Vec<Diagnostic>,
rendered: String,
},
InvalidScale {
scale: f64,
},
MissingConfig {
kind: String,
},
ReadOnlyConfig {
kind: String,
},
Config {
path: Option<Utf8PathBuf>,
message: String,
},
PantryEdit {
message: String,
},
Render {
message: String,
rendered: String,
},
Reference {
name: String,
message: String,
},
Search {
base_dir: Utf8PathBuf,
message: String,
},
InvalidShoppingList {
path: Utf8PathBuf,
message: String,
},
Io {
path: Utf8PathBuf,
source: Error,
},
}Expand description
Errors returned by cookcli-core commands.
Every Display rendering is a single lowercase line with no trailing
newline, so it composes into log lines and error chains. Variants that have
a longer, human-formatted report carry it in a field for the caller to print
separately.
#[non_exhaustive] so that adding variants stays non-breaking for
downstream consumers.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
RecipeNotFound
No recipe could be resolved from the given path or name.
Parse
A recipe failed to parse.
Fields
name: StringHow the recipe is identified in messages. Commands reading from
disk put the file’s path here, so that it agrees with the location
rendered and the diagnostics point at; text parsed from memory
carries whatever name the caller supplied.
diagnostics: Vec<Diagnostic>The individual parse problems, for programmatic consumers.
rendered: StringThe parser’s own multi-line report with source line context, which
the CLI prints verbatim. Not part of Display.
Always free of ANSI escape codes, so it is safe to write to a file
or send over a wire. Callers wanting colour for a terminal should
re-render with render_report and
ansi: true.
InvalidScale
A scaling factor was not a finite number.
Only NaN and infinity are rejected. Zero and negative factors are
accepted, because the CLI accepts them and this crate must not change
that behaviour. NaN is worth catching because a missing JavaScript
argument arrives as undefined, which becomes NaN across NAPI and
would otherwise silently produce NaN quantities.
MissingConfig
A command needed a configuration the context does not carry.
Distinct from CoreError::Config, which means one was supplied and
could not be understood. Not every command needs one:
shopping_list::generate treats an absent pantry as “subtract
nothing”, where the pantry queries cannot, because the pantry is the
thing they report on.
Fields
ReadOnlyConfig
A command that changes a configuration was handed one it cannot write back.
Reached only through ConfigSource::Inline:
an editor holding pantry text in a buffer has somewhere to put an edit,
but this crate has no idea where. Applying the change is the caller’s
to do, or it can supply a
ConfigSource::Path instead.
Distinct from CoreError::MissingConfig, which is having nothing to
change at all.
Fields
Config
A configuration could not be understood.
Fields
path: Option<Utf8PathBuf>The file the configuration came from, absent when it was supplied inline.
PantryEdit
A pantry could not be changed as asked.
The file was read and understood; it is the change that does not apply
— adding an item that is already there, or naming an item or section
that is not. Distinct from CoreError::Config, which is a file that
could not be read as a pantry at all, and from CoreError::Io, which
is a file that could not be read or written.
Nothing has been written when this is returned: every check runs before the pantry is saved.
Render
A report could not be produced from a template and a recipe.
Covers a broken template and a recipe cooklang-reports could not
parse alike, because that crate parses the recipe itself, with its own
parser configuration, from inside the render call — the two failures
arrive down one channel and are not worth guessing apart. A recipe that
fails core’s own parser still yields CoreError::Parse; it is only
report::render that reports both this way.
Fields
rendered: StringThe template engine’s own multi-line report — source location,
error chain, and its hints — which the CLI prints verbatim. Not part
of Display, exactly as CoreError::Parse’s rendered is not.
Reference
A recipe reference could not be expanded into its ingredients.
The referenced recipe was found and parsed; what failed was working out
how much of it the referring recipe wants — an unusable quantity on the
reference, or a target the referenced recipe cannot be scaled to.
Absence and parse failures are CoreError::RecipeNotFound and
CoreError::Parse as usual.
Fields
Search
A directory could not be searched.
Distinct from CoreError::Io because nothing was read: the search
root itself could not be turned into something searchable, so the walk
never started. A root whose name contains glob syntax — notes[2024] —
is the way to reach this, since cooklang-find builds its file pattern
by joining onto the root without escaping it. Reporting that as a failed
read would send the user looking at permissions.
Fields
base_dir: Utf8PathBufThe directory that could not be searched.
InvalidShoppingList
A saved shopping list could not be read as one.
The .shopping-list file was read; it is its contents that could not be
parsed. Distinct from CoreError::Io, which is the file itself being
unreadable, and from CoreError::Parse, which is a recipe.
Reachable because the file is a plain text format users and other Cooklang apps edit directly, so this crate is not the only thing that writes it.
Fields
path: Utf8PathBufThe shopping list that could not be parsed.
Io
A file could not be read or written.
There is deliberately no From<std::io::Error>: every call site must
name the path it was working on. The message stays neutral between
reading and writing, because the variant covers both; the specific
failure is in source.
Fields
path: Utf8PathBufThe file being accessed.
Trait Implementations§
Source§impl Error for CoreError
impl Error for CoreError
Source§fn source(&self) -> Option<&(dyn Error + 'static)>
fn source(&self) -> Option<&(dyn Error + 'static)>
1.0.0 · Source§fn description(&self) -> &str
fn description(&self) -> &str
use the Display impl or to_string()
Auto Trait Implementations§
impl !RefUnwindSafe for CoreError
impl !UnwindSafe for CoreError
impl Freeze for CoreError
impl Send for CoreError
impl Sync for CoreError
impl Unpin for CoreError
impl UnsafeUnpin for CoreError
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> Instrument for T
impl<T> Instrument for T
Source§fn instrument(self, span: Span) -> Instrumented<Self> ⓘ
fn instrument(self, span: Span) -> Instrumented<Self> ⓘ
Source§fn in_current_span(self) -> Instrumented<Self> ⓘ
fn in_current_span(self) -> Instrumented<Self> ⓘ
Source§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
Source§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the foreground set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red() and
green(), which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg():
use yansi::{Paint, Color};
painted.fg(Color::White);Set foreground color to white using white().
use yansi::Paint;
painted.white();Source§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
Source§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
Source§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
Source§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
Source§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
Source§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
Source§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
Source§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
Source§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the background set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red() and
on_green(), which have the same functionality but
are pithier.
§Example
Set background color to red using fg():
use yansi::{Paint, Color};
painted.bg(Color::Red);Set background color to red using on_red().
use yansi::Paint;
painted.on_red();Source§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
Source§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
Source§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
Source§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
Source§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
Source§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
Source§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
Source§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
Source§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
Source§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
Source§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling Attribute value.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold() and
underline(), which have the same functionality
but are pithier.
§Example
Make text bold using attr():
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);Make text bold using using bold().
use yansi::Paint;
painted.bold();Source§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
Source§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi Quirk value.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask() and
wrap(), which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk():
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);Enable wrapping using wrap().
use yansi::Paint;
painted.wrap();Source§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.
fn clear(&self) -> Painted<&T>
renamed to resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.
Source§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the Condition value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted only when both stdout and stderr are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);