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
Multiline error messages are bad for logs #683
Comments
I don't necessarily have a problem with doing something that allows one to print an error message on a single line, but I don't think I'm willing to prioritize the log case over the better UX in the common case. Personally, if it were me, I'd probably just split the error message into lines, drop everything but the last line and log that. I'm not sure the regex crate itself needs to do anything for that. I'm possibly open to other ideas. |
Well, the problem with that is that:
So I was thinking more in the lines of |
Well the main issues here is that strategy to propagate errors is not useful for downstream to provide proper error messages that makes sense for the users, especially, when you try to throw them in GUI applications. Default formatting is bad, but it's subjective, but that's not how you can solve/improve that. The main issue is that the information that So it should look more like. pub enum Error {
/// A syntax error.
Syntax(String, usize, String),
/// The compiled program exceeded the set size limit.
/// The argument is the size limit imposed.
CompiledTooBig(usize),
/// Hints that destructuring should not be exhaustive.
///
/// This enum may grow additional variants, so this makes sure clients
/// don't count on exhaustive matching. (Otherwise, adding a new variant
/// could break existing code.)
#[doc(hidden)]
__Nonexhaustive,
} Where the first element in Note, even
|
Oh, in addition, if default formatting should be changed, I guess library should print a bit more boring debug formatting. Right now it looks like that.
However something like this makes a bit more sense for a library.
|
You can do that today using If you really want to make an earnest argument against the default formatting, then please open another issue. Otherwise, I don't see a reason to continue down that path.
@vorner This sounds like something I might be open to, but to be honest, it seems pretty ham-fisted to me. If you have a requirement that log messages are all one line, then it seems to me like you need to enforce that requirement on your end. |
I'm going to close this for now. I remain open to the idea of exposing some way of emitting single-line error messages. A mutator on the error type itself kind of seems non-ideal. Another possibility is a global flag or perhaps even an option on |
Hello
If there's an error in syntax of regular expression, the
Display
of theError
tries to be helpful and outputs the original pattern with an arrow pointing to the place where it happened.However, I feel like being multiline is not something one would expect from error types. From a more practical perspective, this makes these errors mess up log files, where it is a rule of thumb to never write anything multiline to allow easy grepping through it.
I don't have an idea what exactly to do about the situation ‒ I understand some might like the helpful multiline messages, so removing them completely probably is not the best option, but I'd also like to be able to output errors to logs ‒ and do that in generic way, without knowing what exact error it is, or even have it as one of the error cause.
The text was updated successfully, but these errors were encountered: