Comments (10)
I just realized it isn't blocked by rust-std, actually. The same issue can be reproduced with panic_immediate_abort
, in which case anyhow
is the only dependency pulling in libunwind.
from anyhow.
It may even be not a Cargo feature, just a custom cfg attribute, like Tokio's tokio_unstable
.
That would prevent intermediate libraries setting this mode, and would require a dedicated compilation setting in project.
from anyhow.
On a second thought, std pulls in libunwind even with panic=abort, so perhaps patching anyhow wouldn't achieve a thing. I guess this is blocked by rust-std support. I think I might try to fix that -- is anyone aware of an existing issue, by any change?
from anyhow.
Prior discussions: #239, #256.
Note: dependence on backtraces also complicate compilation on exotic targets that require -Zbuild-std
and does not have backtrace-related symbols like _Unwind_Backtrace
available out of the box.
from anyhow.
See this discussion on Rust forums. If panic tracebacks are enabled with RUST_BACKTRACE=1, anyhow starts attaching tracebacks to every Error object by default. The program cannot prevent this.
The whole idea that non-panic library behavior depends on an environment variable is just wrong. If you catch an error in code and handle it, the backtrace is useless, but uses time. Anything that does considerable network I/O and uses anyhow will generate large numbers of useless backtraces as it handles I/O errors.
On the forums, dumping "anyhow" and using "thiserror" has been suggested.
from anyhow.
I think it's very important that a library using anyhow can choose to disable backtraces without setting an env variable. Libraries should never set env variables for several reasons including 1) setting the variable impacts the app and its use of other libraries, 2) due to the UB warnings in set_var itself and the probability that set_var will be made unsafe in the future.
from anyhow.
I've seen the argument that cargo features are opt-in, thus there can't be a feature that disables backtraces. I think that's a narrow way to view the problem. Indeed, std supports the panic_immediate_abort
feature just fine. I think the main reason std has this allowance is that only the final bin crate is supposed to use this feature, after proving/verifying/assume the software works just fine without smart panic handling. Therefore, I believe a feature to disable backtrace could work just fine if it was explicitly documented to only be used by the bin crate.
from anyhow.
The scenario I was referring to was where a library needs to avoid creation of backtraces in errors, and this should not be under the control of the app. The URLO discussion linked above was about this use case.
from anyhow.
Right. There are many uses of anyhow! that are not followed by an immediate abort. Capturing a backtrace is for unexpected program bugs. If a program handles an error, or just logs it, there's little need for a backtrace. Certainly not one that goes past the point where the error was handled.
from anyhow.
Related Issues (20)
- Use `#[track_caller]` to provide info on where the error was created HOT 1
- Allow source errors to expose their own context? HOT 1
- `build.rs` should not detect nightly feature HOT 11
- [Question] In `{:#?}` why is the outermost context called "caused by" and how is `Context` expected to be used? HOT 1
- `ensure!` macro implementation details HOT 8
- Nightly feature wrongly enabled on stable toolchain HOT 3
- Should `anyhow::Error::chain` return `dyn Error + Send + Sync` HOT 2
- Customize backtrace logic?
- `anyhow!(e)` doesn't preserve `source` for `&Error` HOT 1
- A way to disable anyhow stacktraces (without disabling stacktraces from other crates) HOT 2
- Default Ok-type to `()` in `anyhow::Result` typedef HOT 2
- Updating from version 1.0.76 breaks backtraces HOT 2
- Possible performance regression on Windows HOT 5
- as_ref() type must be known at this point
- Depending on `CARGO_ENCODED_RUSTFLAGS` may produce stale builds HOT 1
- rust-analyzer nightly throws needless_return warning on bail! HOT 2
- Implement Context for Error
- Question regarding stacktrace
- anyhow::Error to Box<dyn Error> isn't compatible with other libraries HOT 2
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 anyhow.