error tags

[dgoffredo]

This revision makes spans aware of the error.msg, error.stack, and error.type tags.

These changes grew out of Andrew Glaude's investigation of compatibility between the C++ tracer and "error tracking": https://docs.datadoghq.com/tracing/error_tracking/.

The new behavior is best summarized by the table of test cases in the added SECTION of test/span_test.cpp.

@ajgajg1134 (he's on vacation) FYI.

Also, when these changes are finalized, we'll want to update these docs: https://docs.datadoghq.com/tracing/trace_collection/custom_instrumentation/cpp/#set-errors-on-a-span

[cgilmour]

Does this still apply?

    // Errors can be a flag or a detailed message.
    // Empty or false-y values indicate no error.
    // Any other value will mark the span to indicate an error occured.

When it's neither falsey or truthy, does it make sense to assign the error tag's contents to error.msg?

[dgoffredo]

The code comment is still true, yes. It would be more true if we set error.msg.

I considered adding the "if neither truthy nor falsy, and not empty, then populate error.msg instead of error" logic. My take is that it's a little harder to remember and explain that policy.

The benefit of the idea, though, is that it means the error tag would only ever be one of these values, which is kind of nice. In all other cases either there would be no error-related tags, or a more descriptive tag would be set instead.

Alright, I'll try it.

[dgoffredo]

Another thought: If someone sets the error tag to an error code value, e.g. errno, then today it works as they might expect: zero means "no error," and other values mean "this is the error code." Moving values like "-2" or "4" to error.msg would mess with that (if that ever actually happens).

[dgoffredo]

Eh, for that we could instead encourage an error.code. The thing to address here is that Datadog thinks of error as a namespace of tags, not as a tag itself. Ok.

[cgilmour]

Might need refactoring at some point, but no real objection about it functionally

[cgilmour]

Not a huge fan of this, but also didn't like the other parts (that I wrote) for handling/parsing boolean values.
And its usage is isolated-enough to not be particularly concerned.

[dgoffredo]

Last chance for name changes. Ideas: enum class Trigun, enum class Tribble, enum class Tribulation, enum class Dribble, enum class Boolble.