Split error enums based on operations

[thomasvl]

I believe this has come up on some PRs, but never got captured.

Currently the source has one large enum for decoding and another for encoding. It likely would be cleaner if there were enums specific to JSON, Binary, and TextFormat, so it is easier for developers to ensure they handle all the relevant errors that they want for a given call.

[tbkka]

Any strong opinions about which of the following would be cleaner?

• Introduce an enum as a subtype: for example, JSONDecoder.Errors
• Add top-level enums similar to the current: JSONDecodingError

I'm leaning towards the first one...

[allevato]

JSONDecoder is essentially an internal type that users don't/shouldn't have to touch directly to use JSON serialization and is only public as an implementation detail, so I'd avoid nesting types that are user-visible in it for that reason. So I'm leaning toward JSONDecodingError, et al.

[tbkka]

A related style issue: There are a number of failure cases for specific WKTs: Timestamp, Duration, and FieldMask, for example, all have additional decoding constraints that can fail.

So if I have JSON {"time": "2017-02-malformed"}, is that a JSONDecodingError.malformedTimestamp or is that a Google_Protobuf_Timestamp.Error.malformed? I think I need to experiment a little to see how these Error enums work in practice...

[tbkka]

So if you catch let e to capture a thrown error and then simply print(e), all you get is the case name, and print(type(of: e)) just shows the immediate type name.

So attaching an Error enum to Timestamp for example isn't all that useful, since after you throw Timestamp.Error.malformed, the easiest information for the user to discover is malformed of type Error. This argues for a flatter approach with relatively verbose error names.

[tbkka]

PR #243 does the first part of this: It splits out the error enums for the decode side.

[tbkka]

PR #300 finishes this; the encoding errors are now also broken out by format.