The error returned by Parser::parse is not std::error::Error

[Kinrany]

I couldn't figure out how to deal with the errors, so I tried to just stuff everything into anyhow::Error. But that doesn't seem to work either 😞

[epage]

ParseError is still a "light weight" error, borrowing all of its content. We could allow explicitly converting to owning the information and implement the trait, but that will be a bit of a crude process.

For lightweight examples, like in our docs, we just do .to_string(). For toml_edit, I convert to a custom error type.

sorry, kept getting distracted from replying

[Kinrany]

ToOwned then? 🙂

[epage]

iirc ToOwned only works with outer references and not inner references.

Like I said, we could have our own method of ParseError::to_owned but the way the data is structured, it would be an odd choice for general use and people likely should be making a more concrete decision rather than assuming its a safe choice if we mamde it too easy.

[dacid44]

Is there any way to easily use .to_string() on an error with a custom token? It looks like the input type (in my case, a slice) needs to impl AsBstr, which I can't do on a slice without a wrapper type. I can use Debug, but that doesn't give me nice error messages. Is there a way to get nice error messages with a custom token at all?

[epage]

For custom tokens, you'll likely need to implement the rendering of the error yourself.

With custom tokens, we have no base assumptions of what is going on for us to provide a nice error message.

[baoyachi]

@epage
I strongly need this feature, currently ParseError is not implemented as std:: err: Error.

At present, I have encountered in the code that includes both business logic judgment and Parser parsing, but I want to use anyhow:: Result, but I found that I cannot use '?' This grammar sugar does not implement StdError, making it quite cumbersome to use

[epage]

ParseError can be converted into a String but most people expect an error to be 'static which a ParseError is not, by default.

So you have to do some adapting to get a ParseError into a commonly accepted format. The fact that it has a Display makes to_string the lowest effort way of doing it which is why I'm not seeing a case for adding a impl Error for ParseError. If people can help in identifying a case, I am open for adding it.

[baoyachi]

I want ParseError to immediately support std::err::Error

[Kinrany]

ParseError can be converted into a String but most people expect an error to be 'static which a ParseError is not, by default.

Perhaps, but that doesn't prevent ParseError from being a useful Error impl when 'static is not required, does it?

Isn't this similar to how, say, PartialEq is accompanied by Eq in almost all cases. But that doesn't mean PartialEq should be avoided for types that cannot implement Eq.

I feel like the only issue here is one of documentation, and it would be enough to have a suggestion for making the error 'static in ParseError's doc comments.

[Kinrany]

The main use case is of course converting to anyhow::Error with just a ? instead of a whole map_err. Adding a map_err is not hard, but that's one extra map_err.

[epage]

Looking back over this because of #606.

The main use case is of course converting to anyhow::Error with just a ? instead of a whole map_err. Adding a map_err is not hard, but that's one extra map_err.

That won't work because anyhow::Error only supports 'static errors, see https://docs.rs/anyhow/latest/anyhow/struct.Error.html#impl-From%3CE%3E-for-Error