[czechdeveloper]

I would just delete that part if it can't be solved. Smaller issues with code are, that you create new string just to compare it (ToLower makes new instance), when you can achieve this just by using proper comparer such as

    ex.InnerException.Message.IndexOf("duplicate", StringComparison.OrdinalIgnoreCase) > -1

Good idea would also be to check for existence of Inner exception at all

    ex.InnerException?.Message.IndexOf("duplicate", StringComparison.OrdinalIgnoreCase) > -1

But I would just live without that check to prevent magical behavior.

[Dayshine]

Yes, because the performance impact of a single string creation in an Exception handler is important.

[mattmanser]

I can't upvote this enough.

I done a fair bit of performance problem fixing now in my career and I have never seen a .ToLower be the cause of any client's performance problems. Or really any string manipulation opinion like stringbuilder vs += and all that nonsense.

[LandR]

If you want to get really picky you should be converting to uppercase and ToUpperInvariant in particular:

From C# via the CLR: Important If you want to change the case of a string's characters before performing an ordinal comparison, you should use String’s ToUpperInvariant or ToLowerInvariant method. When normalizing strings, it is highly recommended that you use ToUpperInvariant instead of ToLowerInvariant because Microsoft has optimized the code for performing uppercase comparisons. In fact, the FCL internally normalizes strings to uppercase prior to performing case insensitive comparisons. We use ToUpperInvariant and ToLowerInvariant methods because the String class does not offer ToUpperOrdinal and ToLowerOrdinal methods. We do not use the ToUpper and ToLower methods because these are culture sensitive.

And from MS

CA1308: https://docs.microsoft.com/en-gb/visualstudio/code-quality/c...

[mattmanser]

Your code is harder to read and the performance implications are so trivial, a classic example of pre-optimization.

[tw1010]

I agree with you. But I also think you're sacrificing clarity over brevity yourself by not expanding "pre-optimization" into "premature optimization" ;)

[biarity]

I myself really dislike that piece of code (searching in exception strings isn't secure for many reasons, for example someone could use this to reverse-engineer information about my database). But the only alternative that comes to mind is to check if an entity exists before attempting to create it - which I don't like because it leads to repetitive code in large projects (and I might forget to write checks). Any other ideas?