Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Error for LoadingError #153

Merged
merged 2 commits into from
Apr 30, 2018
Merged

Implement Error for LoadingError #153

merged 2 commits into from
Apr 30, 2018

Conversation

sharkdp
Copy link
Contributor

@sharkdp sharkdp commented Apr 30, 2018

Implements std::error::Error for LoadingError.

This is a first step towards #94. Things could definitely be improved by also implementing Error for the other syntect-specific errors.

Copy link
Owner

@trishume trishume left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks! Maybe some day syntect should switch to failure or something.

Just one minor duplication cleanup request, but if you don't have time I'll merge this in a few days as is.

src/lib.rs Outdated
WalkDir(ref error) => error.fmt(f),
Io(ref error) => error.fmt(f),
#[cfg(feature = "yaml-load")]
ParseSyntax(_) => write!(f, "Invalid syntax file"),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These cases could be implemented as _ => write!(f, self.description()) instead of duplicating the messages.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason, I didn't think it would work in this direction (because Error depends on fmt::Display).. but that's much better, of course. Updated.

@sharkdp
Copy link
Contributor Author

sharkdp commented Apr 30, 2018

Maybe some day syntect should switch to failure or something.

Yes, a library that removes some of the boilerplate involved in error handling would certainly be a good idea. error-chain seems to be another alternative.

By the way: thank you for this amazing library!

src/lib.rs Outdated
ParseTheme(_) => write!(f, "Invalid syntax theme"),
ReadSettings(_) => write!(f, "Invalid syntax theme settings"),
BadPath => write!(f, "Invalid path"),
ParseSyntax(_) => write!(f, "{}", self.description()),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still not a fan of this duplication. I'd prefer either a _ pattern or if you really want the exhaustiveness checking (I don't think it's important in this case since description is a fine default) you can use a separate item for ParseSyntax and then ParseTheme(_) | ReadSettings(_) | BadPath => for the rest.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry.. just now saw your _ => prefix in the first comment. I've updated it to a catch-all pattern.

Copy link
Owner

@trishume trishume left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@trishume trishume merged commit ac7e7c8 into trishume:master Apr 30, 2018
match *self {
WalkDir(ref error) => error.fmt(f),
Io(ref error) => error.fmt(f),
_ => write!(f, "{}", self.description()),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should not rely on Error::description() since it is going to be deprecated soon?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know that.

Anyhow, it's still required for now and we can easily refactor it to remove it once the default implementation has been stable for a while, or we switch to failure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants