Remove empty branch and add Dbg.Assert in ExportCsvHelper.

[sethvs]

PR Summary

Remove empty branch and add Dbg.Assert in ExportCsvHelper.
Fix #6809

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.
• User-facing changes
  • Not Applicable
  • OR
  • User-facing Documentation needed
    • Issue filed - Issue link:
• Testing - New and feature
  • Not Applicable or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
    • Add [feature] if the change is significant or affects feature tests

[dantraMSFT]

Relying on Dbg.Assert for parameter checking is not a good practice because we don't run tests against Debug builds. I've encountered numerous bugs that relied on Assert for validation but had none in release/production builds.

In this case, the previous code was clearly incorrect but replacing it with a Dbg.Assert doesn't solve it.

I suggest, you make the assignment a condition of non-null or throw an ArgumentNullException when null.

[sethvs]

Fixed.

[iSazonov]

@dantraMSFT Should we review all code base to replace Asserts? Ex., in the file I see same patterns.

[dantraMSFT]

@iSazonov: I would say yes. Assert is perfectly fine if it is used as a debugging aid as long as it has runtime code to back it up. At a minimum, it should be part of any PR review.

[iSazonov]

@daxian-dbw @TravisEz13 Should we add @dantraMSFT's suggestion in our PR check list?

[TravisEz13]

@iSazonov I think this comes to the level of something that should be documented guidance, but not something that should be in the checklist for every PR. If it should be verified for every PR, we should probably write a test to verify that this code is not in any changed code blocks.