Allow returning errors in HTTPTracingService

[mjungsbluth]

Allow returning errors in HTTPTracingService

[ashutosh-narkar]

The ability to return an error seems like a good idea.

a backwards compatible change would be introducing a second interface that can validate tracing.Options

Are you suggesting a new Validate method on the Options type? This would also work, correct?

[mjungsbluth]

Are you suggesting a new Validate method on the Options type? This would also work, correct?

That is also possible but is also a breaking change as far as I can see it. I was more thinking of another interface with a validate method that implementations HTTPTracingService can implement.

I am actually not sure how much concern just adding error as return type is as this interface is pretty specific to library use and also easy to fix (just return nil as err in the changed method signature)

[ashutosh-narkar]

I am actually not sure how much concern just adding error as return type is as this interface is pretty specific to library use and also easy to fix (just return nil as err in the changed method signature)

You're probably correct but we don't know the impact of the breaking change. So another interface that returns an error and maybe takes a context as input if it makes sense would be better. We can deprecate the old one.

As the tracing options are passed as an untyped array, errors in construction of these options can happen.

Question: Where does the validation happen? Inside the NewTransport implementation?

[mjungsbluth]

Question: Where does the validation happen? Inside the NewTransport implementation?

In my case yes. Causes can be type mismatches or missing elements.

[ashutosh-narkar]

Ok. So a new interface that returns an error and deprecating the old seems like a good option to me.