-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Rejig error hierarchy #224
Conversation
Looks fantastic Nikolaus 👍 |
I came across this in https://github.com/liborty/indxvec/blob/964de9f78a89844bd651f6709aff86f88751ff67/src/lib.rs#L5-L16 in case it happens to be helpful for the error handling revisions: /// macro `here!()` gives `&str` with the current `file:line path::function` for error messages.
#[macro_export]
macro_rules! here {
() => {{
fn f() {}
fn type_name_of<T>(_: T) -> &'static str {
std::any::type_name::<T>()
}
let name = type_name_of(f);
format!("\n{}:{} {}", file!(), line!(), &name[..name.len()-3])
}}
} |
Glyph loading errors are a bit finicky. There's dealing with XML, UFO spec compliance and builder logic 🤔 |
|
c665502
to
3c64ad2
Compare
Hm. I am probably falling into the traps described in https://www.unwoundstack.com/blog/rust-error-handling.html#org579e4a9. I'll try to reduce variants somewhat. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One little nit, but I think this is an improvement!
Possible to push a new release that includes the updated error handling that was merged over the last couple of months? |
Already done today 😁 |
The latest release and tag that I see is https://github.com/linebender/norad/releases/tag/v0.6.0 from Oct 2021? |
It looks like crates.io was updated with a new release (v0.7.0). I checked the tags/releases here. Thanks! |
This experimental PR implements a more layered error hierarchy for better visibility into the error chain.
Example, messing with the
x
attribute for a point:It is not entirely possible to have the detailed errors be private, as we expose several public methods that now return them. This made me think: Should we expose e.g.
FontInfo::from_file
and theLayerSet::load
andLayer::load
methods as public?TODO:
Better errors for Glif parsing,better done in a separate PRGlifLoadError::Parse
is a bit non-descript