I haven't contributed to ClosedXML in a while, trying to get back into it, would be willing to work on this. Would the desired behavior here be to throw an exception?

Alright, I looked into this, obviously it's fairly easy to add a check, but I don't want to without sign off from one of the main contributors. The reason being is, adding a check for a space, would actually result in a change in the existing behavior that might cause a backwards incompatibility for users.

Currently during workbook save when serializing the TablePartDefinitionXml there is a call to GetTableName which has a call to RemoveSpecialCharacters which is normalizing the table name by removing any spaces. This means the saved file is not corrupt.

For if example if I set the table name to "Table With Spaces" it will be saved as "TableWithSpaces"

Fixing this would mean we break existing users in the wild if they were relying on this behavior

Not fixing it means you have hidden side effects if you do a round trip. Meaning if you open the saved file you generated with ClosedXml you can't access the table by the name "Table With Spaces" you would have to know the internals stripped away spaces and would have to access it by the normalized named "TableWithSpaces"

@jahav what behavior would you prefer?

Make the get table by name functionality use the same functionality so that when table name with spaces or other weirdness is sent in, it fixes the key for the developer.

In the scenario that I was using was important that the name is correct.
External System ---> table names with spaces ----> closedXML
Changing table names inside closedXML is a very dangerous solution in my opinion... The probability to think in every scenarios that the bad name (with spaces) can be used in the code can be huge...

I think the throwing error is the most correct. Is important the code has a coherent answer to dev errors. But this is my opinion.

@NickNack2020

I think it would be better to reject invalid name with an exception. Name of a table is not just an identifier, but it can also be used formulas structured references (e.g. SUM(SalesTable[Profit])).

I am in favour of simple, understandable interfaces and contracts and principle of least surprise. Having a name sanitizer inside is not in line with that.

I would therefore refuse any invalid table names. We already throw an exception There is already a table names 'Xyz' when if someone tries to add a table with duplicate name. This only enhances the contract to be correct.

Please add a note/mitigation about change to the https://github.com/ClosedXML/ClosedXML/blob/develop/docs/migrations/migrate-to-0.101.rst + info in XML doc.

Spec says

A string representing the name of the table. This is the name that shall be used in
formula references, and displayed in the UI to the spreadsheet user.
This name shall not have any spaces in it, and it shall be unique amongst all other
displayNames and definedNames in the workbook. The character lengths and
restrictions are the same as for definedNames. See SpreadsheetML Reference -
Workbook definedNames section for details