Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Overriding Display for Error Types? #31

Open
zicklag opened this issue Dec 11, 2019 · 4 comments
Open

[Question] Overriding Display for Error Types? #31

zicklag opened this issue Dec 11, 2019 · 4 comments

Comments

@zicklag
Copy link

zicklag commented Dec 11, 2019

I've got a quick question about the varlink generated error types. Take this generated code for example:

pub enum ErrorKind {
    Varlink_Error,
    VarlinkReply_Error,
    Error(Option<Error_Args>),
    HookFailed(Option<HookFailed_Args>),
}

I have two user-defined errors in my .varlink file: Error, and HookFailed. My question is, why are the error arguments inside of an Option? According to the varlink definition, the error must have the arguments that I have defined, so in what cases would the error Arguments be None? I'm mostly trying to figure out if a None value in this case should be a panic, or whether or not that can happen in normal operation.

@zicklag
Copy link
Author

zicklag commented Dec 16, 2019

As a related note, the reason I'm trying to figure this out is because I want to override the Display implementation of the Varlink errors. Right now I'm planning on using Regex to replace the existing display implementation with my own, but that seems hackish. Do you have any other ideas for a way to do this?

@zicklag zicklag changed the title [Question] Why Are Error Arguments Option<Error_Args>? [Question] Overriding Display for Error Types? Dec 16, 2019
@haraldh
Copy link
Collaborator

haraldh commented Dec 17, 2019

Hmm, easiest thing would be a generator option specifying not to generate the Display trait.

@zicklag
Copy link
Author

zicklag commented Dec 17, 2019

The way I did it was I replaced the generated implementation with an include! so that it would include my implementation from another file. We could add an alternative_display_impl option that would be an Option<&Path> maybe.

@phi-gamma
Copy link

Hmm, easiest thing would be a generator option specifying not to generate the Display trait.

That would be useful for other traits too. I just tripped over the
PartialEq trait which I need to behave differently
(array should be treated as equivalent irrespective of the order
of elements) than the derived one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants