Investigate Box<dyn Error> to un-stringify errors
!443 (merged) simplifies LoadingError
and RenderingError
, the error types for the public API, but it turns some variants into having a String
detail instead of a more structured thing.
Part of the reason for that is that those error variants cross abstraction boundaries. RenderingError::Rendering(String)
means that Cairo exploded; LoadingError::XmlParseError(String)
is just a human-readable version of libxml2's xmlError
.
I don't think the public error types should expose implementation details like cairo::Status
or xmlError
. I am not sure what to do about LoadingError::Io(String)
; it was a general LoadingError::Glib(glib::Error)
before, but that was the wrong abstraction.
Could we use something around Box<dyn Error>
effectively for those cases that cross abstraction boundaries? What's the state of the art in error-related crates for libraries (is it thiserror
?). There are a lot of crates for error reporting in application code, but for libraries it is different.