Allow disabling Msg variant in ErrorKind

[leoschwarz]

The main reason why I'd want that is to force a more strict handling and categorization of errors in my code, and it's currently my main pain point pushing me towards manual error type definition again. So instead of just writing Err("blabla".into()) (the main problem is that it's rather hard finding all these in your code base) I would have to think about adding or using a variant which describes the exact error better, and would subsequently allow downstream users of my crates to programatically handle some of the possible errors.

I'm not sure if just (optionally) removing the Msg variant would break things like chaining though?

[Yamakaky]

That would be a good thing. Do you want to try a PR?

Not really, you can just use your own variant instead of using a string.

[leoschwarz]

Ok, I'll try coming up with something in the next couple days.

At first I thought this could be done using a cargo feature, but then I realized this might be an issue if some crates in a dependency graph have it enabled while some don't. So it will probably have to be done in a way that it can be configured using the macro. Personally I would also like if #182 could be disabled individually.

Now I'm not sure if this kind of configuration is possible with the current macros, or if this is blocked on #170.

[Yamakaky]

#170 is more long term, we can improve the macro meanwhile.

[faern]

This is a feature I would really like as well. Any well designed library should not throw Msg errors IMO, and thus it should not be a variant in the ErrorKinds for libraries either.

@leoschwarz Did you get anywhere on this yet? Anything I can do to help?

[leoschwarz]

I got quite busy and still am until the end of the week, so all my Rust projects are currently on hold. However I'm glad to see it implented in derive-error-chain for now. :) I'm not a macro expert so I got a bit overwhelmed, but I'll either take another shot at it when this week is over or if you want you can take this over. Design wise it has to be done in the macro and not using cargo features, as I explained above. I'm not even really sure what kind of syntax to use (it's usually a struggle to find something that doesn't cause ambiguities), derive-error-chain now just requires the `Msg(String)` variant to be added by hand (i.e. opt in) whereas I feel this might not be wished here as most people will still want the `Msg` variant. On the other hand it follows the principle of least surprise, doing "less magic" (it also makes even more sense for that crate as the enum is specified using the usual syntax). However this is a real design choice and I can't decide this just like that. Figuring out the syntax is probably also relevant to #182 which I personally feel should be optional too. Maybe we could use attrs but I'm not sure if this is possible using old style macros. (That's like all I've thought about this so far.) Am 23.08.2017 um 02:04 schrieb Linus Färnstrand:

…

This is a feature I would really like as well. Any well designed library should not throw |Msg| errors IMO, and thus it should not be a variant in the |ErrorKind|(s) for libraries either. @leoschwarz <https://github.com/leoschwarz> Did you get anywhere on this yet? Anything I can do to help? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#200 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIr8nF_yAplqnSO13ONiu2B3EiTFMHEUks5sa2ybgaJpZM4Ol3WS>.

[Arnavion]

derive-error-chain now just requires the
Msg(String) variant to be added by hand (i.e. opt in) whereas I feel
this might not be wished here as most people will still want the Msg
variant.

To be clear, derive-error-chain has always needed the variant to be added by hand, since custom derives cannot modify the definition of the item they're applied to. It's just that it used to be required and I've made it optional.

(At one point when proc macros were not yet stabilized, they could modify the item definition, and back then derive-error-chain itself added the Msg member for the user. It's a lucky coincidence in retrospect that being forced to add it then allows it to be optional now.)

[faern]

I personally wish we could make it opt-in in error-chain as well. But I realize that would probably break way too much code(?), so I guess the only change that will be acceptable is to change it from a forced variant to one you can opt out of?

Personally I don't see a problem with making it opt-in, since we do have semver to clearly state they are incompatible. But many crate maintainers tend not to agree :)

[faern]

I have played with this a bit. But I have not found a nice way to do it yet. Not going to invest too much time since it's a nice to have feature, but not critical.