Span Error Handler

[devinsba]

This supports the case where certain backend systems support errors as a first class object.

XRay supports encoding errors in their model directly. Having a configurable error handler in brave will allow a zipkin-aws functionality for storing them for reporting to the backend

[codefromthecrypt]

For the sake of conventions, lets switch this to line up with the other parsers and use a default implementation. We've been using classes to prevent subtle changes from affecting people.. and basically everywhere we use interfaces has been difficult. Here's something I just ripped from HttpParser. Mind swapping out your interface for that? I don't think we need a noop as we already have noop span and this isn't done in the other parsers.

public class ErrorParser {
  /**
   * Override to change what data from the error are parsed into the span modeling it. By
   * default, this tags "error" as the message or simple name of the type.
   */
  public void error(Throwable error, SpanCustomizer customizer) {
    String message = message = error.getMessage();
    if (message == null) message = error.getClass().getSimpleName();
    customizer.tag("error", message);
  }
}

With this in place, the existing code can use it.. ex changing HttpParser, GrpcParser etc subtypes..
make sense?

[codefromthecrypt]

thanks for taking a crack at this.. has been on the mind for a long time @devinsba!

[codefromthecrypt]

discussed with @devinsba offline. I will take this on to try and help land this in time for sleuth's next RC. This means we can obviate more code there

[codefromthecrypt]

made changes according to feedback so far. need some README updates etc

[codefromthecrypt]

ok I think I am done here. working on the startScopedSpan now

[shakuzen]

LGTM

[codefromthecrypt]

Note: I added a commit to make this work with the new scoped span without forcing the latter to implement SpanCustomizer f1e3a0c

[devinsba]

LGTM, had to reread the HttpTracing changes a couple times to understand what was going on at first, but it makes sense. Thanks for finishing this up for me.

Re HttpTracing: it wasn't clear at first that the lines overriding the errorParser were so the one configured in the Tracer is the one that is used instead of the default at first

[codefromthecrypt]

here's WIP of sleuth consuming this feature spring-cloud/spring-cloud-sleuth#928

[codefromthecrypt]

#684 for XML

[codefromthecrypt]

going out in 4.19.0