Opaque Error Type

[AerialX]

The 0.9 API no longer exposes any structured details about errors that occur (moved to ErrorImpl and became private). I need to determine whether a parsing error failed due to various reasons (missing required field, unexpected field, wrong data type, etc) along with the field name that caused the error.

I imagine the motivation behind this change was to provide it in a more generic way at the serde crate level? Do I need to wrap the deserializer somehow and intercept the creation of the error object to extract this information? Parse the error description messages?

[dtolnay]

The motivation was to allow for error enhancements like #173 to be made in a non-breaking way. Can you explain in more detail the way that your code needs to treat the various error cases differently? We may be able to solve this in a way that does not prevent us from improving our errors in the future.

[AerialX]

Specifically, I'm implementing an API server spec that defines discrete user-facing error codes for missing field, wrong data type, and unexpected field. The field name being accessible separately is optional, as the spec only requires a freeform descriptive error message alongside the code.

This is currently implemented with a From<json::Error>, and generating the appropriate error code and message with a match.

[jonhoo]

Related to this, the current (opaque) error type is pretty tricky to work with. I had to go to the source to find out that Error implements Into<io::Error> (well, using From really...), and there doesn't seem to be a way to go another way. This is problematic for functions with a signature like

fn foo<W: Write>(w: &mut W) -> serde_json::Result<()> {}

that want to, say, first write something on w, and then serialize something into it. You can now longer use w.write_all(b"bar")?; inside, because io::Error cannot be turned into a serde_json::Error (even though that's clearly not true).

[jmorrell]

To add another use-case, I'm trying to build a cli tool to give expressive errors when Node's package.json contains syntax errors.

Motivating Examples:

4 |  "engines": {
5 |    "node": "8.1.x"
  |            ^^^^^^^ Missing trailing comma
6 |    "yarn": "0.24.6"
7 |  },

20 |  "dependencies": {
…  |    
34 |    "semver": "^5.3.0",
35 |    "supertest": "^3.0.0",
                     ^^^^^^^^^ Extra trailing comma
36 |  }

Error: An additional trailing comma was found in your list of 
       dependencies. This usually happens when you manually 
       delete a dependency. In the future consider using the command:
       
       $ npm uninstall <package name>

https://github.com/serde-rs/json/issues/173 would be helpful, but not having access to the ErrorCode is the first obstacle I ran into: https://github.com/serde-rs/json/blob/master/src/error.rs#L183

I could format the format the error as a string and switch on that output, but having access to the enum would be far preferable if possible.

[Sh4rK]

I ran into the exact same problem as @jmorrell above.

I want to pretty print JSON errors, but the only way to get a specific, non-debug formatted error is via the Display impl, but that also includes position information, and I only need the message.

Example error: expected `,` or `}` at line 9 column 43.

Looking at the source, I would basically need to access ErrorCodes Display impl.

(Of course I can work around this by string matching the location info and cutting it off, or parsing the error from the Debug impl, neither of which is really nice.)

[Jezza]

Is there any progress or update on this?
I'm happy to help anyway I can.

We're trying to implement nicer error handling/reporting, and serde_json hiding impl details away is blocking us.
We're close to either dropping serde_json completely (and with it the whole serde eco-system), or trying to work out a way to extract the information from the strings. (Needless to say, quite painful.)

[AshleySchaeffer]

Just ran into this. For me if we could just have a getter method that returns a borrow of the ErrorCode enum from the Error type that would be plenty.