Should there be such a thing as a `null` activeSpan()? Or SpanContext?

Now that #115 is in, we need to contend with the scenario where ActiveSpanSource.activeSpan() / Tracer.activeSpan() returns null.

As I see it, there are three options.

1. Do nothing. Callers check for null and get on with their lives.
2. Specify that implementations use some sort of NoopSpan, but do not specify which
3. Specify that implementations use a particular instance of a particular object… maybe NoSpan.INSTANCE instead of NoopSpan.INSTANCE. I.e., the caller could do equality testing and be guaranteed to check for the “no-span Span” without adding a new isReal() sort of method to the Span interface. Of course the various tagging methods would do nothing here.

There is the related case of Tracer.extract() when there’s, well, nothing to extract. Should it return null, an unspecified non-null SpanContext, or a particular SpanContext instance to represent the case of being absent?

See also https://github.com/opentracing/opentracing-java/pull/115/files/bf4606c596955c7e353cfa92bba372d5ecd2e206#r114108185 and https://github.com/opentracing/opentracing-java/pull/115/files/bf4606c596955c7e353cfa92bba372d5ecd2e206#r109821172 where this came up. And also https://github.com/opentracing/opentracing-java/pull/111#discussion_r111682133 .

[ryonday]

Begging you to just return a NoopSpan or something if there’s no active span.

[ivantopo]

Hey @bhs, this is definitely not a “every day” coding situation, most people will be just fine with the instrumentation provided by the libraries. This is just to have a safe experience when it happens that you are required to tweak the instrumentation to cover some corner cases on how you application is implemented or doing “manual instrumentation”. I ended up creating a few utility functions that help our code hide the null checks and provide a safer API to the users, but that doesn’t prevent anyone from doing something like Kamon.activeSpan().setBaggageItem("my-thing", "my-value") and ending up throwing a NPE.

I understand that Java developers might be used to do null checks because, well, it’s Java, that’s how things have been done historically… but things are moving towards safer ways of writing code (think about Optional making it into Java!) and I would say it’s in the best interest of the OT spec to provide safety in all cases, even the less common ones.