Comments (7)
I absolutely agree that library code should not use anyhow. (You might consider thiserror
as a more convenient replacement for quick-error
with some additional features, but that's more a matter of taste.)
I was purely talking about contexts where you currently use boxed errors.
from gitoxide.
For libraries, I would prefer keeping quick-error, but possibly box big enum variants to keep the size small, allowing users of these functions to actually see what went wrong programmatically.
There some spots in the code that use Box<dyn Error + Send + Sync>
, but it's portions of code that don't have anyhow available, and I would like to avoid that dependency unless truly, truly required.
gitoxide-core
and higher use anyhow
as they are considered application level.
Unless there are performance issues, I would avoid switching just because I am so happy with the error handling story in this project so far. And I have tried a lot :D - and feel like I finally arrived.
from gitoxide.
thiserror
I evaluated, and then I found quick-error in an old project of mine and realized that these 200ish lines of macro is all I need. thiserror
pulls in a bunch of dependencies and increases compile times to the point where I can't justify its benefits.
Some of my decisions are driven by my constraints, after all I am working on a tiny machine (MB Air 2020, 8GB of RAM, 4 cores) :D. It's a good thing, and I will hold on to it for that very reason and resist the urge to go all 'ARM' ;).
from gitoxide.
@Byron Did you evaluate that before or after the change that made build-time-only dependencies use opt-level 0?
from gitoxide.
from gitoxide.
I have just added thiserror
for use in one particular error type, resolving some limitations of quick-error in that particular instance. It's very nice, too, here my highlights (and for when I will use it):
- support for generic errors (and I will revise some error types in
git-odb
which could benefit from that) - support for 'transparent' errors - often I find myself adding a quite generic 'quick-error' display message because the detailed message is contained in the source(). There I doubt the generic message adds much value most of the time.
The drawbacks of thiserror
clearly is the dependency chain, which one pays once, and probably most projects do pull syn
and procmacro2
in one way or another.
So in short, I think it's worth using when needed, for these features alone.
Right now it seems I will keep using quick-error
, but switch to thiserror
for particular Errors that require its additional feature set.
from gitoxide.
Closing this for now, since performance-critical cases already do this. There might be value in switching, but not for performance.
from gitoxide.
Related Issues (20)
- Oxidize Radicle-Git HOT 7
- Oxidize comtrya HOT 1
- Oxidize `comtrya` HOT 4
- another parsing failure of malformed author/committer timestamp HOT 2
- gix-transport 0.41.3 has issues HOT 6
- unread field warnings on nightly HOT 1
- Availability: crates.io vs releases HOT 5
- gix_submodule::File::from_bytes is a catch22 HOT 4
- some way to refresh in-memory packed refs cache without relying on mtime HOT 2
- Panic receiving pack if fetch interrupted HOT 2
- `gix clone` ignores global `core.symlinks` on Windows HOT 8
- Checking out a dangling symlink on Windows is treated as a hard error HOT 3
- CI install-action now fails on Windows, can't find .cargo/bin
- 16 tests fail on Windows with GIX_TEST_IGNORE_ARCHIVES=1 HOT 1
- Tests on Windows require Git Bash or a similar environment HOT 1
- Assertion failure crash in `gix_date::time::write::<impl gix_date::Time>::write_to` HOT 3
- `core.excludesFile` config entry exists but has blank value causes error: is this considered a bug or expected behavior? HOT 1
- Nondeterministic macOS `is_symlink` assertion failure in `overwriting_files_and_lone_directories_works` HOT 1
- Backport outside traversal fix to v0.62.x HOT 2
- Installing `[email protected]` via `cargo install` not possible because the `zip` crate in the specified verision is yanked HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gitoxide.