You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current errors tend to be very noisy, with long chains of Arrow Error:, mix of internally and externally provided sources and messy stack traces. I ran into this blogpost by the greptime people, which outlines a pretty elegant solution with very nice outcomes, both performance wise and UX wise.
I think we should consider adopting a similar approach, either by using whatever they end up extracting into a separate crate or building it on our own.
the main goals as I see them are:
Keep the general ergonomics of thiserror - nice From implementations for external types, ability to specify internal Vortex errors.
Better and more relevant stack traces - should inform user about concrete problems and issues, without having 50 lines of tokio/datafusion/random functions
Keep the error type(s?) useful for Vortex users
Obviously good performance/binary size etc.
The text was updated successfully, but these errors were encountered:
Current errors tend to be very noisy, with long chains of
Arrow Error:
, mix of internally and externally provided sources and messy stack traces. I ran into this blogpost by the greptime people, which outlines a pretty elegant solution with very nice outcomes, both performance wise and UX wise.I think we should consider adopting a similar approach, either by using whatever they end up extracting into a separate crate or building it on our own.
the main goals as I see them are:
thiserror
- niceFrom
implementations for external types, ability to specify internal Vortex errors.The text was updated successfully, but these errors were encountered: