Comments (6)
I wonder if we could do something like
#[cfg(backtrace)]
struct Backtrace(...);
#[cfg(not(backtrace))]
struct Backtrace;
This would lift the need for each library to add the conditional compilation. It might also allow them to avoid adding a feature flag, as the application author could be responsible for adding snafu = { features: [backtrace ] }
to their Cargo.toml. Then the library author just has to ensure they add a Backtrace
field where appropriate.
from snafu.
General plan:
- The
backtraces
feature is disabled by default - SNAFU unconditionally has a
Backtrace
type, encouraging error type authors to include it in their types. - When the application author enables the
backtraces
feature, the SNAFUBacktrace
type starts to carry abacktrace::Backtrace
. - The
backtrace-crate
feature impliesbacktraces
and adds theAsRef
implementation as shown in this PR. It wouldn't need to return anOption
because of the requirement onbacktraces
. - In the future, we could add a
backtrace-std
feature that also impliesbacktraces
. It would be incompatible with thebacktrace-crate
feature, but only an application should enable it so this shouldn't be a problem. At that point in time, we could also implementAsRef
for the standard libraryBacktrace
type.
For a library author, they just scatter Backtrace
in all of their leaf errors (and backtrace(delegate)
in aggregating errors, for now).
An application author adds features = [backtraces]
and optionally one of backtrace-crate
, backtrace-std
(sometime), if they need to access the underlying type.
from snafu.
as the top-level consumer is no more in charge of those features
But the consumer is not actually in charge of this. The library creating the error already has to add a Backtrace
type to each corresponding error variant:
#[derive(Snafu)]
enum Error {
Something { backtrace: Backtrace }
}
With your proposed end result, every crate will also need to
-
Add a feature flag for backtraces
-
Add conditional compilation to each
backtrace
field:#[derive(Snafu)] enum Error { Something { #[cfg(my-backtraces)] backtrace: Backtrace } }
These multiple steps make me worried that library authors simply won't use backtraces at all, negating any benefits.
There's an inherent tension around default features. Without a feature by default, people get confused because "the docs show it's there, but it doesn't work for me". With a feature by default, time and space can be wasted on unused functionality.
Additionally, there's tension between library usage and application usage. Libraries should strive to be minimal in what they bring in to better work in more contexts, but applications tend to want to be maximal.
Anecdotally, library crates do a poor job of using default-features = false
.
and can't directly opt-out.
Can you provide some concrete cases where such a thing would be beneficial? Presumably you are encountering one "in the wild" to prompt the request.
from snafu.
Another point is that eventually, backtraces will be added to the standard library. This will essentially make it "free" to use a backtrace.
from snafu.
Thanks for the very quick feedback!
I don't have a direct report from the field, as I'm still in the planning phase of migrating my existing crates (e.g. caps
) to snafu
, but I've encountered the same friction with both failures
and error-chain
.
I maintain a mix of both libraries and applications. For the former, it is painful to keep tracking and disabling default features, in order to let application developers being in control. For the latter, opt-ing out default features through chained dependencies becomes a game of whack-a-mole.
You suggestion of an inert Backtrace
type makes sense to me. Additionally in that case, direct consumers should be able to enable your feature directly via --features snafu/backtraces
.
from snafu.
I didn't see opposition to this and the plan above seemed well-rounded, so I proceeded and opened a PR at #157.
from snafu.
Related Issues (20)
- alternate `Display` to include the source chain HOT 4
- Best way to consolidate error types HOT 9
- Investigate switching `IntoError` from an associated type to generics HOT 2
- Investigate adding `ResultExt::boxed` and `::boxed_local`
- Is it possible to automatically include fields in error's display? HOT 2
- Consider adding #[snafu(transparent)] HOT 6
- Support Serde for the built-in types HOT 6
- multiple error types (struct and enum) and generic `IntoError` HOT 2
- Simple context usage, mysterious compile error HOT 2
- Use the same deprecation macros on the no_std Error as the official Error HOT 3
- Add an ensure macro that works with pattern matching HOT 2
- Restore support for yeeting context selectors HOT 1
- Print multi-line errors on their own lines in `Report` HOT 2
- Const generics seem to be giving the derive macro trouble HOT 2
- question: Best practice for automatic error conversion over two module levels?
- Cannot use a generic with a whatever variant
- Incorrect year in changelog
- No apparent way to have an error enum variant documentation generated from a display string HOT 5
- Why isn't Whatever Send + Sync by default? HOT 5
- `Report` print doesn't prefix with "Error: " 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 snafu.