Comments (10)
I think sticking a #[cfg(feature = "std")]
on the impl will be enough for now. It's not very clear what benefits adding a new trait will have, especially without buy-in from the ecosystem.
from snafu.
I think sticking a
#[cfg(feature = "std")]
on the impl will be enough for now.
Without implementing error::Error
, what benefits would people get from SNAFU? I'm not arguing, I just don't fully understand it yet.
from snafu.
An error enum with conversions, possibly backtrackes (?) and optional no_std compat, I guess.
from snafu.
I guess.
Are you interested in using SNAFU in a no-std environment? If so, which aspects are you looking for?
backtrackes
I don't think this is possible as Backtrace
appears to require std.
optional no_std compat
Isn't that what we are talking about? To put it another way, every crate could have a no-std mode. In the worst case, everything in the crate would be disabled. I hope you'd agree that such a switch would not be useful, however.
That's what I'm trying to determine — what is the usefulness of SNAFU when it doesn't have access to the standard library?
from snafu.
Are you interested in using SNAFU in a no-std environment? If so, which aspects are you looking for?
No, not right now. I've published an optional no-std crate, but I used a hand-written enum for it. I didn't consider snafu
when I've written it.
I don't think this is possible as Backtrace appears to require std.
Ah, okay. I was on my phone and couldn't check.
Isn't that what we are talking about? To put it another way, every crate could have a no-std mode. In the worst case, everything in the crate would be disabled.
The crate I mentioned earlier has optional std support for two things:
- `serde/std
- implementing
std::error::Error
on its error type
what is the usefulness of SNAFU when it doesn't have access to the standard library?
Having the conversions might be enough for some. If people are using failure
, they could probably use snafu
if that Error
impl was feature-gated.
from snafu.
I used a hand-written enum for it
What interface does that enum present to the user who consumes it? How do they make use of an error type that doesn't implement Error
? Do they just use the Display
implementation?
Having the conversions might be enough for some.
This is a benefit to the library author, certainly, and I can see how it might be nice.
If people are using
failure
, they could probably usesnafu
Sure, which is why I opened this issue in the first place, but I don't yet understand the benefits of using either Failure or SNAFU in a no-std crate.
from snafu.
Thank you for this conversation, by the way!
from snafu.
As somebody who recently started migrating from failure
to snafu
, I would like to express my interest in no-std support as well. One of my use cases is to have a crate which contains definitions of several different enums that are used in a protocol for communication between a host computer and a microcontroller connected by USB. These for example implement TryFrom<u8>
for mapping bytes of the communication stream to the enum variants. It would be helpful if I could use these implementations in the microcontroller firmware.
I recently really started to enjoy the convenience I get from using snafu
in terms of ease of use (ensure!()
macro, .context()
method etc.) and would love to use these items in the microcontroller firmware implementation.
My current options are to either duplicate some implementation details (e.g. an alternative implementation of TryFrom
behind a feature flag), to migrate away from snafu
now that I really started to like the convenience, or to duplicate the whole enum definitions, leading to an increased effort in keeping this synchronized. I would really love to see no-std support for snafu
(without backtrace
support in this case, so I would put the backtrace
fields of my error variants behind a feature flag).
from snafu.
I’m open to having this happen. As I understand it, the plan basically needs to be:
- Find all usages of
std::
in snafu-derive and replace them withcore::
equivalents. - For the ones that have no equivalent (hopefully just
std::error::Error
), provide no-op replacements viaif cfg!(feature = "std”)
(see existing examples for backtraces). - Define that feature flag in snafu-derive and snafu. It should be optional and off-by-default in snafu-derive and optional and on-by-default in snafu. snafu should enable the feature in snafu-derive.
- The hardest part IMO is writing a test for this. I have yet to figure out how to write a no-std test other than by grepping the rlib’s symbols for
std
which is exceedingly brittle.
from snafu.
FWIW: backtrace-rs could in theory be no_std and in fact std is an optional feature, although I suspect all current backends require std (maybe the goblin/addr2line backend doesn't ?)
I am personally working on a project (custom OS) that will eventually involve a no_std backtrace implementation. At that point, snafu will make a lot of sense for me for error handling as it provides:
- A very ergonomic way to transform errors through the context system
- "Automagic" backtrace support
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.