Comments (18)
In fact, would you be OK to merge our two repos?
from derive-error-chain.
so that the two could be used together
I don't think this will work. If I implemented it here it would be a completely new ChainedError trait for each errorkind struct (similar to how ChainIter / make_backtrace are emitted once for each errorkind), so it won't interop with error_chain::ChainedError
.
In fact, would you be OK to merge our two repos?
Sure, but how would it work given that the codegen is completely separate? macro_rules vs proc_macro_derive function?
from derive-error-chain.
There is only one ChainedError
trait, unlike the old ChainErr
trait.
from derive-error-chain.
Yes, but since there is no $crate
for proc macros, this crate will need to emit a separate ChainedError
trait for each errorkind, just like it emits separate ChainIter
and make_backtrace
instead of using a single $crate::
one.
from derive-error-chain.
I think we can do like with serde
, where they have serde
which defines the traits and serde_derive
for the macro 1.1. In this case, you have to extern crate
the two of them. It would work the same for our use-case.
from derive-error-chain.
That makes sense. I can change this one's output to use the error_chain::
exported traits and expect users to use both.
from derive-error-chain.
And serde
and serde_derive
are in the same crate ;)
https://github.com/serde-rs/serde
from derive-error-chain.
In this case, you have to extern crate the two of them.
In Serde we use the following hack to work around this. We expand:
#[derive(Serialize)]
struct Point {
/* ... */
}
... into:
const _IMPL_SERIALIZE_FOR_Point: () = {
extern crate serde as _serde;
impl _serde::Serialize for Point {
/* ... */
}
};
This way it works whether or not the user's code has extern crate serde
. For instance the example in the readme does not have it.
from derive-error-chain.
Hum, didn't know this trick, thanks!
from derive-error-chain.
Adding @brson to the conversation.
from derive-error-chain.
@dtolnay the user still have to put serde
in Cargo.toml
?
from derive-error-chain.
the user still have to put
serde
inCargo.toml
?
Yes they do.
from derive-error-chain.
BTW, macros 1.1 should be in stable
in a few weeks now, so this crate is bound to replace the macro.
from derive-error-chain.
so this crate will replace the macro.
Well... I wouldn't go that far just yet. There are a few inconveniences compared to error_chain!
due to limitations of proc macros:
- Need to have an explicit
Msg(String)
variant - Need to annotate every non-chained variant with a
#[error_chain]
attribute to specify foreign or custom - Need to implement
description()
anddisplay()
as separate fully-written-out functions. (Atleast for the former, I've been thinking of changing the attribute to also take indescription = constant("Some string")
in addition todescription = "path_to_description_function"
). Edit: #6 and #7
from derive-error-chain.
@Yamakaky I'm done with the port to use error_chain traits, with one snag.
Because the latest release 0.6.1 doesn't have this commit the codegen of derive-error-chain can't use State::backtrace()
either. Do you plan to make a new release with that commit soon, or should I switch to the 0.6.1 version (direct access to State::backtrace
field depending on backtrace feature) ?
from derive-error-chain.
Can you use master
for now? I'd rather not do a release every few days.
from derive-error-chain.
Okay, I'll keep it in a separate branch then.
from derive-error-chain.
Thank you. I already have a breaking syntax change on master, and I'm trying to fix the last one I'm aware of. Please ping me if I haven't made a new release in a week or two ;)
from derive-error-chain.
Related Issues (20)
- Port error-chain's tests
- Support specifying custom `Error::cause`
- Replace `error_chain!` HOT 6
- Make Sync configurable
- Future alias? HOT 1
- Make Msg optional
- Rename `#[derive(error_chain)]` to `#[derive(ErrorChain)]`
- Don't require `ErrorKind` to be `pub`
- Update pm2, syn, quote for nightly breakages
- Switch to new proc_macro_derive
- Undocumented dependencies HOT 4
- Support deriving on structs
- Update for error-chain v0.12.0 HOT 4
- Allow backtrace to be optional
- Update example and tests for #[cfg] on variants
- Add `const("some string literal")` as a shorthand for `description()` HOT 2
- Add `const("some string literal with {parameters}")` as a shorthand for `display()` HOT 4
- Change display and description to receive all members instead of a tuple of the members
- Documentation updates
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 derive-error-chain.