Pretty-printing of decoding failure history about circe

[artempyanykh]

I see that CursorOp already has Show instance defined, and string representations of operators are already pretty visual there.

@tobias-johansson in his PR:

1. collapsed array traversals which is very reasonable since you hardly ever want to see 27 arrows on the screen -> instead of [27], and
2. changed the repr. of downField from --\\(field)" to .field.

These 2 things probably covers 80% of use-cases. For other Ops it just fallbacks to the already defined Show. Which gives us pretty much what I wanted to do minus a couple extra line-breaks 😃

@travisbrown do you think that going for the original output format is still relevant (comparing them side by side)?

[↴ array]
  →|→|→|→|→|→|→|→|→|→|→|→ × Int
// and
Decoding Failure at [12]: Int

From #222 (comment),

DecodingFailure at .bar.baz.qux.a: String

looks really nice! What might be cool though is adding a current focus to the error message so it gives a bit more context

DecodingFailure at .bar.baz.qux.a: decoding 10 as String

[artempyanykh]

I can take a look into it in a couple weeks after I get back from vacation.

[travisbrown]

👍, this sounds great.

[tobias-johansson]

From gitter: https://gitter.im/travisbrown/circe?at=56d079f2d2637aec24d4ccd8

WIP
I've done some work on a Show[DecodingFailure] that tries to make simple, compact messages by representing the cursor history as javascript style selection, i.e. "DecodingFailure at .foo.bar[2].baz: some message".
I believe this is a good idea if you want to return error messages to http clients, etc.

WIP can be seen here: master...tobias-johansson:Show-DecodingFailure
It deals with normal navigation operations, and if there are other kinds of operations it falls back to Show[CursorOp] for those.

Problem
The error messages could still be improved though, and I would like to discuss if it's possible to encode the reason for failure in DecodingFailures in a better way.
At the moment if I do

scala> decode[Int](""""a"""")
res8: cats.data.Xor[io.circe.Error,Int] = Left(io.circe.DecodingFailure: Int)

the message in the DecodingFailure is simply the string "Int" which isn't of much help when trying to create a nice error message.

Suggestion
I'm suggesting an explicit encoding of the reason to replace or complement the message field in DecodingFailure, something like:

sealed trait Reason
case class TypeExpectation(expected: String) extends Reason
case class FailedValidation(message: String) extends Reason
case object FailedCursor extends Reason

This would make it easy to create or customize error messages, or otherwise interpret failures, without the need to embed the full messages in Decoder etc.
The downside might be that DecodingFailure is public api along with some other things like Decoder[A].withErrorMessage and I'm not sure how to deal with that.

What do you think?

[artempyanykh]

@tobias-johansson nice! I had similar idea in regard to implementation, but the JS-selection-like output scales better.

[travisbrown]

Quoting myself from Gitter:

@tobias-johansson That sounds like reasonable output for Show[DecodingFailure]. I think it'd make sense to have the visualization that @artempyanykh describes in #188 be available as something like a draw method on DecodingFailure, while the Show instance gives the more compact representation you describe.

So while #222 is merged, I think we should leave this issue open for the original more visual output proposed by @artempyanykh.