remove unreachable ?? new ConsoleExporterOptions() in ConsoleExporter

[SimonCropp]

Fixes #
Design discussion issue #

Changes

since it cant be null

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.39%. Comparing base (89ea5c6) to head (92d22dd).
Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6079      +/-   ##
==========================================
- Coverage   86.39%   86.39%   -0.01%     
==========================================
  Files         257      257              
  Lines       11640    11639       -1     
==========================================
- Hits        10056    10055       -1     
  Misses       1584     1584              

Files with missing lines	Coverage Δ
.../OpenTelemetry.Exporter.Console/ConsoleExporter.cs	63.63% <ø> (-3.04%)	⬇️

[Kielek]

I am fine with this change, but there is one comment to this.
Historically, this project was released without Nullability check. When introduced, this kind of checks stays in place to avoid any hidden breaking changes. What is more, it is still possible to pass null here by null forgiving operator !/disabling nullability in the project. IMO the problem is similar to the Debug.Assert discussed in #6101

[CodeBlanch]

I don't think this is the correct direction.

This is a public API. We can't control what users will pass it. Even though we say it shouldn't be null (via the nullable annotations), it is still possible for users to pass null.

It probably should have been written like this:

    protected ConsoleExporter(ConsoleExporterOptions options)
    {
       Guard.ThrowIfNull(options);

       this.options = options;
    }

But technically a breaking change to do now.

If we really want to clean up the oddity, why not just embrace the fact that it allows null?

-   protected ConsoleExporter(ConsoleExporterOptions options)
+   protected ConsoleExporter(ConsoleExporterOptions? options)
    {
        this.options = options ?? new ConsoleExporterOptions();

[Kielek]

More to consider:

• OTLP Exporter - Debug.Assert
• Zipkin Exporter - Guar.ThrowIfNull
• Prometheus Exporter - Gurad.ThrowIfNull
• In Memory - no options class

I would say that we should have common behavior in all these exporters. I do no think that adding support for null value will be the best option. The question is, if the constructor behavior can be changes and it can throw the exception.
If we decide to go this way, OTLP Exporter should be also modified. IMO worth to add a changelog note, that the behavior was fixed/changed.

[xiang17]

Should we bundle this kind of "minor" breaking change with other breaking changes in a future major version? Or it's ok to just go and change them now?

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.