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

Serialization errors can only be created from the Encoder/Decoder methods #15036

Closed
huonw opened this issue Jun 19, 2014 · 4 comments
Closed

Comments

@huonw
Copy link
Member

huonw commented Jun 19, 2014

There is no way for a custom generic Decodable/Encodable instance (compatible with #[deriving] other) to return a new error since it's completely generic, that is,

#[deriving(Decodable)]
struct Foo {
    x: Bar
}

struct Bar { y: int }

// E has to be that generic to work with the deriving above,
// but this means this impl cannot manually create new errors
// (e.g. if y is supposed to be an even number, there's no way
// to emit "error: found odd number".)
impl<E, D: Decoder<E>> Decodable<D, E> for Bar { ... }

It might be nice if there was a E: Error trait (or some such) that deriving used, which has some basic constructors.

@huonw
Copy link
Member Author

huonw commented Jun 25, 2014

This might be somewhat addressable by having an method like fn error(&self, msg: &str) -> E on Decoder/Encoder (allowing a decoder to e.g. insert line/column information), although it may need to be more detailed.

@huonw
Copy link
Member Author

huonw commented Jun 26, 2014

cc @erickt

apoelstra added a commit to apoelstra/rust that referenced this issue Aug 1, 2014
A quick and dirty fix for rust-lang#15036 until we get serious decoder reform.

Right now it is impossible for a Decodable to signal a decode error,
for example if it has only finitely many allowed values, is a string
which must be encoded a certain way, needs a valid checksum, etc. For
example in the libuuid implementation of Decodable an Option is
unwrapped, meaning that a decode of a malformed UUID will cause the
task to fail.

Since this adds a method to the `Decoder` trait, all users will need
to update their implementations to add it. The strategy used for the
current implementations for JSON and EBML is to add a new entry to
the error enum `ApplicationError(String)` which stores the string
provided to `.error()`.

[breaking-change]
bors added a commit that referenced this issue Aug 1, 2014
A quick and dirty fix for #15036 until we get serious decoder reform.

Right now it is impossible for a `Decodable` to signal a decode error, for example if it has only finitely many allowed values, is a string which must be encoded a certain way, needs a valid checksum, etc. For example in the `libuuid` implementation of `Decodable` an `Option` is unwrapped, meaning that a decode of a malformed UUID will cause the task to fail.
@aturon
Copy link
Member

aturon commented Aug 15, 2014

cc rust-lang/rfcs#201

@alexcrichton
Copy link
Member

This was fixed for Decoder and otherwise Encoder is stabilized so we can't change this any more. As a result, closing.

lnicola pushed a commit to lnicola/rust that referenced this issue Jun 19, 2023
…=Veykril

internal: Give ConstBlockId and InTypeConstId named Location types

cc rust-lang/rust-analyzer#14932
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