Reporting on malformed trace context

[yurishkuro]

Why is #355 a good change? There's another PR #359 that catches and logs all exceptions in the codecs. I think it's better to log an error saying that the inbound trace context was malformed than to silently ignore it, which makes it much harder for the user to figure out what's going on.

cc @jpkrohling

[jpkrohling]

#355 was about avoiding an exception under our control. From a security perspective, we do not want to let end-users control when an exception occurs on the server side, as they are usually expensive. That said, I should indeed have added a log statement where we previously had an exception.

#359 is about dealing with faulty third-party injector/extractor (TextMap implementations) and catching their unavoidable (to us) exceptions. As a library that is embedded into a business application, we should try to never bubble exceptions thrown at or below our level.

cc @tmszdmsk

[tmszdmsk]

#359 would do all the job that's needed to prevent issues with malformed input.

Throwing exceptions is idiomatic to java but I agree that in this specific case it is better to do it "exceptionless" as we are able to handle that exception anyway. Some log message would be useful though.

[jpkrohling]

Can this one be closed? I think this was resolved by #362.