Handle exceptions from Tracer.Extract

The Tracer.Extract method today returns an ISpanContext object. This can be null if no TracerId or SpanId were found. There is a possibility that the extract method throws an exception if something goes wrong. If the user forgets to catch this exception the user program will crash.

Compare with the Go version, extract returns a Tuple<context, error>. Here context is always nil if extract was unsuccessful, with a reason in the error property. Error types are ErrSpanContextNotFound, ErrUnsupportedFormat, ErrSpanContextCorrupted, ErrInvalidCarrier or implementation-specific errors.

A suggestion is to mimic the same behavior for C#. If we have

public interface ITracer
{
   ...
   public ExtractResult Extract(format, carrier)
   ...
}

public class ExtractResult
{
   public ISpanContext SpanContext { get; }
   public bool Success { get; }
   public Exception Exception { get;}
}

In this way the user always get a SpanContext back that could be used in Tracer.StartSpan (since null is a valid startSpan parameter). The user also has the possibility to check the error and react on but it is not mandatory. And most important, it will not throw exceptions that the user needs to handle.

[dawallin]

The TryExtract patter with an out parameter was the original behavior. It has 2 disadvantages. If extract fails, the user can’t extract why. And the out parameter does not work with async/await. I don’t know if we ever need async in extract, but if it is a stream as a carrier then maybe.

I see tracing just as logging. From the Serilog documentation, and I know log4net does the same thing.

Serilog takes the view that, all things considered, logging is a lower priority than other application code and should never avoidably impact the operation of a running application.

Think I’ve seen something about this somewhere around opentracing as well. I prefer that the implementation can do internal logging if something goes wrong but swallows all exceptions. With the result pattern the user can, but are not forced to determine if there was an error. It is then possible for the user to rethrow if he/she likes to.

[cwe1ss]

I’ll close this as the discussion for this has to happen either in opentracing/specification or in opentracing-java.