-
Notifications
You must be signed in to change notification settings - Fork 532
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
Clarify the role of DecodingFailure's "message" #306
Comments
Without knowing the particular piece of code overly well, your suggestions seem like a good first approach. Have you tried it and seen how the code pans out? |
Just my €0.000002: Personally, I'd be very much in favour of more descriptive error messages. I think, compared to |
My preference is actual error classes representing common error cases. This gives the developers freedom to transform a decoding error into w/e output they need. I think these should cover the common errors:
|
While this is being pondered it would be nice to just use the Show instance added in #222 to produce the message. That way we would get the nice javascript-style path for the history which is much more usable for bigger documents. |
Update sbt-dotty to 0.5.0
Closing in cleanup run, If anyone cares about this, please comment and I'll reopen. |
circe's
DecodingFailure
is a descendant of Argonaut's(String, CursorHistory)
inDecodeResult
, and in Argonaut there's some ambiguity about what the string represents—in some places it's just a string representation of the type, and in other places it's a more detailed message about what went wrong. Since it doesn't have a name in Argonaut (and the corresponding argument to e.g.DecodeResult.fail
is just nameds
), the library doesn't seem to make any particular commitment to how the string should be interpreted.I originally planned to provide more guidance here in circe, but we're at version 0.5 and
message
inDecodingFailure
is still playing both roles, and now the newDecodingFailure.fromThrowable
in #303 puts a printed stack trace in the message field, which introduces yet another kind of thing that it can do.I'd be interested in any suggestions about how we can refine the fields in
DecodingFailure
to make it clear what each one should do. One straightforward approach would be just to add new fields: something likename: String
,message: String
, an optionalunderlying: Option[Throwable]
, and the lazyCursorHistory
, but I'm definitely open to other ideas.The text was updated successfully, but these errors were encountered: