Replies: 2 comments 1 reply
-
To be completely transparent: The reason this has come up for me is I'm using miette to report parsing errors and building a serde deserializer on top of that. The chance of someone using miette to |
Beta Was this translation helpful? Give feedback.
-
eyreish has always been a temporary measure, until provide-any landed, so you could have |
Beta Was this translation helpful? Give feedback.
-
My take: miette is doing a bit too much by being an eyreish and providing a
Report
type. It should focus on just providing theError
type (derive).For use in libraries, you already recommend just using
#[derive(Error, Diagnostic)]
, and not usingReport
.For use in applications, you provide
Report
andIntoDiagnostic
.IntoDiagnostic
is effectively lossy: it wraps an arbitraryimpl Error
into effectively a "null object"impl Diagnostic
which providesNone
for all of its diagnostic info. The underlying error is seen throughError::source
.GraphicalReportHandler
does render the source chain, at least, andwrap_err
maintains the diagnostic information.But I'm not certain exactly what benefit
miette::Report
provides over usingeyre::Report
. It feels to me that whatmiette
wants is an eyreSection
for the diagnostic information.What I'm most concerned about, I guess, is that I make a nice
miette
diagnostic for my library's error, and then none of it is seen unless the application sticks that error into amiette::Report
. If the error is wrapped by another library, the information is lost unless it passes through the diagnostic info.I honestly don't know the "correct" or "best" solution here. But at least to me it feels like miette is trying to be two things -- a general purpose error reporting library, and a specialized parsing error library -- but not really excelling at either. (Specifically, the requirement of
'static
gets in the way of use for parsing libraries which parse&str
, since it requires a source clone.)What I'm doing for the right now in my library is just providing a non-
'static
Diagnostic
and pointing at how to use aReportHandler
to render it, providing astatic_diagnostic() -> impl Copy + Diagnostic
which strips the source information (since it's a parsing library, the caller has the source and can re-inject it), and ato_owned() -> miette::Report
which useswith_source_code
onmiette!(self.static_diagnostic())
to attach the source info in an owned manner.At the very least, though, even if
Report
is kept, a decent amount of eyre's complexity could be trimmed off; the fact that the reporting hook creates a separate report handler for everymiette::Report
seems excessive; I don't really see a use case for downcasting and providing different report handlers for different concrete diagnostic types, and just registering a global&'static ReportHandler
can reduce complexity there.I'll be completely honest and say that as part of writing this down I'm less certain in my position now, but it still feels to me that miette can and should use eyre rather than being an eyreish. (The point of eyre is to be pluggable, after all, especially color-eyre.)
Beta Was this translation helpful? Give feedback.
All reactions