Niedawno pracowałem z DateTimeobiektem i napisałem coś takiego:

DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?

Dokumentacja intellisense AddDays()mówi, że dodaje dzień do daty, a tak nie jest - w rzeczywistości zwraca datę z dodanym dniem, więc musisz napisać:

DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date

Ten raz mnie ugryzł wiele razy, więc pomyślałem, że przydałoby się skatalogować najgorsze gotówki C #.

private int myVar;
public int MyVar
{
    get { return MyVar; }
}

Blammo. Aplikacja ulega awarii bez śladu stosu. Dzieje się cały czas.

(Zwróć uwagę na kapitał MyVarzamiast małych liter myVarw getterze).

Type.GetType

Ten, który widziałem, gryzie wiele osób Type.GetType(string). Zastanawiają się, dlaczego to działa dla typów w ich własnym zestawie, a niektóre typy lubią System.String, ale nie System.Windows.Forms.Form. Odpowiedź jest taka, że ​​wygląda tylko w bieżącym zestawie i w mscorlib.

Anonimowe metody

C # 2.0 wprowadził anonimowe metody, prowadząc do takich nieprzyjemnych sytuacji:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            ThreadStart ts = delegate { Console.WriteLine(i); };
            new Thread(ts).Start();
        }
    }
}

Co to wydrukuje? Cóż, to całkowicie zależy od harmonogramu. Wydrukuje 10 liczb, ale prawdopodobnie nie wydrukuje 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, czego można się spodziewać. Problem polega na tym, że izostała przechwycona zmienna, a nie jej wartość w momencie tworzenia delegata. Można to łatwo rozwiązać za pomocą dodatkowej zmiennej lokalnej o odpowiednim zakresie:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            int copy = i;
            ThreadStart ts = delegate { Console.WriteLine(copy); };
            new Thread(ts).Start();
        }
    }
}

Odroczone wykonanie bloków iteratora

Ten „test jednostkowy biednego człowieka” nie przechodzi - dlaczego nie?

using System;
using System.Collections.Generic;
using System.Diagnostics;

class Test
{
    static IEnumerable<char> CapitalLetters(string input)
    {
        if (input == null)
        {
            throw new ArgumentNullException(input);
        }
        foreach (char c in input)
        {
            yield return char.ToUpper(c);
        }
    }

    static void Main()
    {
        // Test that null input is handled correctly
        try
        {
            CapitalLetters(null);
            Console.WriteLine("An exception should have been thrown!");
        }
        catch (ArgumentNullException)
        {
            // Expected
        }
    }
}

Odpowiedź jest taka, że ​​kod w źródle CapitalLetterskodu nie zostanie wykonany, dopóki nie MoveNext()zostanie wywołana metoda iteratora .

Na mojej łamigłówce są jeszcze inne dziwactwa .

Ponowne zgłaszanie wyjątków

Gotcha, która dostaje wielu nowych programistów, to semantyka wyjątków ponownego rzucania.

Dużo czasu widzę następujący kod

catch(Exception e) 
{
   // Do stuff 
   throw e; 
}

Problem polega na tym, że czyści ślad stosu i znacznie utrudnia diagnozowanie problemów, ponieważ nie można śledzić, skąd pochodzi wyjątek.

Poprawnym kodem jest albo instrukcja throw bez argumentów:

catch(Exception)
{
    throw;
}

Lub zawinięcie wyjątku w inny i użycie wewnętrznego wyjątku, aby uzyskać oryginalny ślad stosu:

catch(Exception e) 
{
   // Do stuff 
   throw new MySpecialException(e); 
}

Okno obserwacyjne Heisenberga

To może cię źle ugryźć, jeśli robisz rzeczy na żądanie, takie jak to:

private MyClass _myObj;
public MyClass MyObj {
  get {
    if (_myObj == null)
      _myObj = CreateMyObj(); // some other code to create my object
    return _myObj;
  }
}

Powiedzmy teraz, że masz jakiś kod gdzie indziej, używając tego:

// blah
// blah
MyObj.DoStuff(); // Line 3
// blah

Teraz chcesz debugować swoją CreateMyObj()metodę. Więc umieściłeś punkt przerwania na linii 3 powyżej, z zamiarem wkroczenia do kodu. Na wszelki wypadek umieściłeś również punkt przerwania na linii powyżej _myObj = CreateMyObj();, a nawet punkt przerwania w CreateMyObj()sobie.

Kod uderza Twój punkt przerwania na linii 3. Wchodzisz do kodu. Oczekujesz wprowadzenia kodu warunkowego, ponieważ _myObjjest oczywiście zerowy, prawda? Uh ... więc ... dlaczego to pominęło warunek i poszło prosto do return _myObj?! Najedziesz myszką na _myObj ... i rzeczywiście ma wartość! Jak to się stało?!

Odpowiedź jest taka, że ​​twoje IDE spowodowało, że uzyskało wartość, ponieważ masz otwarte okno „obserwuj” - zwłaszcza okno obserwacyjne „Autos”, które wyświetla wartości wszystkich zmiennych / właściwości odpowiednich dla bieżącego lub poprzedniego wiersza wykonywania. Kiedy osiągniesz punkt przerwania na linii 3, okno obserwacyjne zdecydowało, że będziesz zainteresowany, aby poznać wartość MyObj- więc za kulisami, ignorując dowolny z punktów przerwania , poszedł i obliczył MyObjdla ciebie wartość - w tym wezwanie do CreateMyObj()tego ustawia wartość _myObj!

Dlatego nazywam to oknem zegarka Heisenberga - nie można obserwować wartości bez wpływu na nią ... :)

GOTCHA!

Edycja - Uważam, że komentarz @ ChristianHayter zasługuje na uwzględnienie w głównej odpowiedzi, ponieważ wygląda na skuteczne obejście tego problemu. Więc zawsze, gdy masz leniwie załadowaną właściwość ...

Udekoruj swoją właściwość za pomocą [DebuggerBrowsable (DebuggerBrowsableState.Never)] lub [DebuggerDisplay („<załadowany na żądanie>”)]. - Christian Hayter

Oto kolejny raz, który mnie dopada:

static void PrintHowLong(DateTime a, DateTime b)
{
    TimeSpan span = a - b;
    Console.WriteLine(span.Seconds);        // WRONG!
    Console.WriteLine(span.TotalSeconds);   // RIGHT!
}

TimeSpan.Seconds to część sekund przedziału czasu (2 minuty i 0 sekund ma wartość 0).

TimeSpan.TotalSeconds to cały przedział czasu mierzony w sekundach (2 minuty mają całkowitą wartość 120).

Wyciek pamięci, ponieważ nie odblokowałeś zdarzeń.

To nawet złapało niektórych starszych programistów, których znam.

Wyobraź sobie formularz WPF z dużą ilością rzeczy, a gdzieś tam subskrybujesz wydarzenie. Jeśli nie anulujesz subskrypcji, cały formularz zostanie zachowany w pamięci po zamknięciu i usunięciu odwołania.

Wydaje mi się, że problem, który widziałem, polegał na utworzeniu DispatchTimer w formularzu WPF i subskrybowaniu zdarzenia Tick, jeśli nie zrobisz - = na zegarze, twój formularz wycieka pamięć!

W tym przykładzie twój kod porzucenia powinien mieć

timer.Tick -= TimerTickEventHandler;

Ten jest szczególnie trudny, ponieważ utworzyłeś instancję DispatchTimer w formularzu WPF, więc pomyślałbyś, że będzie to wewnętrzne odwołanie obsługiwane przez proces czyszczenia pamięci ... niestety DispatchTimer używa statycznej wewnętrznej listy subskrypcji i usług żądań w wątku interfejsu użytkownika, więc odwołanie jest „własnością” klasy statycznej.

Może nie jest to naprawdę problem, ponieważ zachowanie jest napisane wyraźnie w MSDN, ale raz złamało mi kark, ponieważ uznałem, że jest to raczej sprzeczne z intuicją:

Image image = System.Drawing.Image.FromFile("nice.pic");

Ten facet pozostawia "nice.pic"plik zablokowany, dopóki obraz nie zostanie usunięty. W tamtym czasie pomyślałem, że fajnie byłoby ładować ikony w locie i nie zdawałem sobie sprawy (na początku), że skończyło mi się z dziesiątkami otwartych i zablokowanych plików! Obraz śledzi, skąd załadował plik ...

Jak to rozwiązać? Myślałem, że jeden liniowiec wykona zadanie. Spodziewałem się dodatkowego parametru FromFile(), ale go nie miałem, więc napisałem to ...

using (Stream fs = new FileStream("nice.pic", FileMode.Open, FileAccess.Read))
{
    image = System.Drawing.Image.FromStream(fs);
}

Jeśli liczyć ASP.NET, powiedziałbym, że cykl życia formularzy internetowych jest dla mnie całkiem spory. Spędziłem niezliczone godziny debugując źle napisany kod formularzy internetowych, tylko dlatego, że wielu programistów po prostu nie rozumie, kiedy użyć obsługi zdarzeń (niestety).

przeciążone == operatory i nieopakowane kontenery (tablice zestawów, zestawy danych itp.):

string my = "my ";
Debug.Assert(my+"string" == "my string"); //true

var a = new ArrayList();
a.Add(my+"string");
a.Add("my string");

// uses ==(object) instead of ==(string)
Debug.Assert(a[1] == "my string"); // true, due to interning magic
Debug.Assert(a[0] == "my string"); // false

Rozwiązania?

• zawsze używaj, string.Equals(a, b)gdy porównujesz typy ciągów

• używając generics, List<string>aby upewnić się, że oba operandy są łańcuchami.

[Serializable]
class Hello
{
    readonly object accountsLock = new object();
}

//Do stuff to deserialize Hello with BinaryFormatter
//and now... accountsLock == null ;)

Morał tej historii: Inicjatory pola nie są uruchamiane podczas deserializacji obiektu

DateTime.ToString („dd / MM / rrrr”) ; To nie zawsze da ci dd / MM / rrrr, ale weźmie pod uwagę ustawienia regionalne i zastąpi separator daty w zależności od tego, gdzie jesteś. Więc możesz dostać dd-MM-rrrr lub coś podobnego.

Właściwym sposobem na to jest użycie DateTime.ToString („dd” / „MM” / „yyyy”);

DateTime.ToString („r”) ma konwertować na RFC1123, który używa GMT. GMT znajduje się w ułamku sekundy od UTC, a jednak specyfikator formatu „r” nie konwertuje na UTC , nawet jeśli dana godzina jest określona jako Lokalna.

Powoduje to następującą gotcha (różni się w zależności od odległości czasu lokalnego od UTC):

DateTime.Parse("Tue, 06 Sep 2011 16:35:12 GMT").ToString("r")
>              "Tue, 06 Sep 2011 17:35:12 GMT"

Ups!

Widziałem ten opublikowany innego dnia i myślę, że jest dość niejasny i bolesny dla tych, którzy nie wiedzą

int x = 0;
x = x++;
return x;

Jak to zwróci 0, a nie 1, jak większość by się spodziewała

Jestem trochę spóźniony na tę imprezę, ale mam dwie bzdury, które niedawno mnie ugryzły:

Rozdzielczość DateTime

Właściwość Ticksa mierzy czas w 10 milionowych części sekundy (100 nanosekundowych bloków), jednak rozdzielczość nie wynosi 100 nanosekund, to około 15 ms.

Ten kod:

long now = DateTime.Now.Ticks;
for (int i = 0; i < 10; i++)
{
    System.Threading.Thread.Sleep(1);
    Console.WriteLine(DateTime.Now.Ticks - now);
}

da ci wynik (na przykład):

0
0
0
0
0
0
0
156254
156254
156254

Podobnie, jeśli spojrzysz na DateTime.Now.Millisecond, otrzymasz wartości w zaokrąglonych porcjach o wielkości 15.625 ms: 15, 31, 46 itd.

To szczególne zachowanie różni się w zależności od systemu , ale w tym interfejsie API daty / godziny istnieją inne problemy związane z rozdzielczością .

Path.Combine

Świetny sposób na łączenie ścieżek plików, ale nie zawsze działa tak, jak można się spodziewać.

Jeśli drugi parametr zaczyna się od \znaku, nie da ci pełnej ścieżki:

Ten kod:

string prefix1 = "C:\\MyFolder\\MySubFolder";
string prefix2 = "C:\\MyFolder\\MySubFolder\\";
string suffix1 = "log\\";
string suffix2 = "\\log\\";

Console.WriteLine(Path.Combine(prefix1, suffix1));
Console.WriteLine(Path.Combine(prefix1, suffix2));
Console.WriteLine(Path.Combine(prefix2, suffix1));
Console.WriteLine(Path.Combine(prefix2, suffix2));

Daje ci ten wynik:

C:\MyFolder\MySubFolder\log\
\log\
C:\MyFolder\MySubFolder\log\
\log\

Po uruchomieniu procesu (przy użyciu System.Diagnostics), który zapisuje na konsoli, ale nigdy nie czyta strumienia Console.Out, po określonej ilości danych wyjściowych aplikacja będzie się zawieszać.

Brak skrótów operatora w Linq-To-Sql

Zobacz tutaj .

Krótko mówiąc, wewnątrz warunkowego klauzuli kwerendy LINQ-SQL, nie można używać skrótów warunkowe jak ||i &&aby uniknąć wyjątków odniesienia null; Linq-To-Sql ocenia obie strony operatora OR lub AND, nawet jeśli pierwszy warunek eliminuje potrzebę oceny drugiego warunku!

Używanie parametrów domyślnych z metodami wirtualnymi

abstract class Base
{
    public virtual void foo(string s = "base") { Console.WriteLine("base " + s); }
}

class Derived : Base
{
    public override void foo(string s = "derived") { Console.WriteLine("derived " + s); }
}

...

Base b = new Derived();
b.foo();

Wyjście:
podstawa pochodna

Wartościuj obiekty w kolekcjach zmiennych

struct Point { ... }
List<Point> mypoints = ...;

mypoints[i].x = 10;

nie ma wpływu.

mypoints[i]zwraca kopię Pointobiektu wartości. C # szczęśliwie pozwala modyfikować pole kopii. Po cichu nic nie robiąc.

Aktualizacja: Wydaje się, że zostało to naprawione w C # 3.0:

Cannot modify the return value of 'System.Collections.Generic.List<Foo>.this[int]' because it is not a variable

Być może nie najgorsze, ale niektóre części .NET używają stopni, podczas gdy inne używają radianów (a dokumentacja, która pojawia się z Intellisense nigdy nie mówi ci, które, musisz odwiedzić MSDN, aby się dowiedzieć)

Można tego wszystkiego uniknąć, Anglezamiast tego mając klasę ...

Dla programistów C / C ++ przejście na C # jest naturalne. Jednak największa gotcha, na którą natknąłem się osobiście (i widziałem, jak inni dokonują tego samego przejścia), nie do końca rozumie różnicę między klasami i strukturami w języku C #.

W C ++ klasy i struktury są identyczne; różnią się jedynie domyślną widocznością, gdzie klasy domyślnie są widoczne dla prywatności, a struktury domyślnie - dla widoczności publicznej. W C ++ ta definicja klasy

    class A
    {
    public:
        int i;
    };

jest funkcjonalnie równoważny tej definicji struktury.

    struct A
    {
        int i;
    };

Jednak w języku C # klasy są typami referencyjnymi, a struktury są typami wartości. To sprawia, że DUŻA różnica w (1) podejmowaniu decyzji, kiedy użyć jednego nad drugim, (2) testowaniu równości obiektu, (3) wydajności (np. Boksowaniu / rozpakowywaniu) itp.

W sieci dostępne są wszelkiego rodzaju informacje związane z różnicami między nimi (np. Tutaj ). Gorąco zachęcam każdego, kto przejdzie do C #, aby przynajmniej miał praktyczną wiedzę na temat różnic i ich konsekwencji.

Odśmiecanie i usuwanie (). Chociaż nie musisz nic robić, aby zwolnić pamięć , nadal musisz zwolnić zasoby za pomocą Dispose (). Jest to niezwykle łatwa rzecz do zapomnienia, gdy używasz WinForms lub śledzisz obiekty w jakikolwiek sposób.

Implementacja tablic IList

Ale nie wdrażaj go. Gdy zadzwonisz do Add, powiesz, że to nie działa. Dlaczego więc klasa implementuje interfejs, gdy nie może go obsługiwać?

Kompiluje, ale nie działa:

IList<int> myList = new int[] { 1, 2, 4 };
myList.Add(5);

Często mamy ten problem, ponieważ serializator (WCF) zamienia wszystkie ILists w tablice i otrzymujemy błędy czasu wykonywania.

zakres zmiennych pętli foreach!

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    l.Add(() => s);
}

foreach (var a in l)
    Console.WriteLine(a());

wypisuje pięć „amet”, podczas gdy poniższy przykład działa dobrze

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    var t = s;
    l.Add(() => t);
}

foreach (var a in l)
    Console.WriteLine(a());

MS SQL Server nie może obsłużyć dat sprzed 1753 r. Co istotne, nie jest zsynchronizowany ze DateTime.MinDatestałą .NET , która wynosi 1/1/1. Więc jeśli spróbujesz uratować umysł, zniekształconą datę (jak ostatnio przydarzyło mi się to podczas importu danych) lub po prostu datę urodzenia Wilhelma Zdobywcy, będziesz miał kłopoty. Nie ma wbudowanego obejścia tego problemu; jeśli prawdopodobnie będziesz musiał pracować z datami sprzed 1753 r., musisz napisać własne obejście.

Nasty Linq Caching Gotcha

Zobacz moje pytanie, które doprowadziło do tego odkrycia, oraz blogera, który odkrył problem.

W skrócie, DataContext utrzymuje pamięć podręczną wszystkich obiektów Linq-do-Sql, które kiedykolwiek załadowałeś. Jeśli ktokolwiek dokona jakichkolwiek zmian w rekordzie, który wcześniej załadowałeś, nie będziesz w stanie uzyskać najnowszych danych, nawet jeśli jawnie ponownie go załadujesz!

Wynika to z właściwości wywoływanej ObjectTrackingEnabledw obiekcie DataContext, która domyślnie ma wartość true. Jeśli ustawisz tę właściwość na false, rekord będzie ładowany od nowa za każdym razem ... ALE ... nie możesz zachować żadnych zmian w tym rekordzie za pomocą SubmitChanges ().

GOTCHA!

Kontrakt na Stream.Read jest czymś, co widziałem, że podróżuje do wielu osób:

// Read 8 bytes and turn them into a ulong
byte[] data = new byte[8];
stream.Read(data, 0, 8); // <-- WRONG!
ulong data = BitConverter.ToUInt64(data);

Powodem tego jest to, że Stream.Readodczytuje co najwyżej określoną liczbę bajtów, ale może całkowicie odczytać tylko 1 bajt, nawet jeśli kolejne 7 bajtów jest dostępnych przed końcem strumienia.

To nie pomaga, że to wygląda tak podobne do Stream.Write, które jest gwarantowane napisałem wszystkie bajty jeśli zwróci bez wyjątku. Nie pomaga również to, że powyższy kod działa prawie cały czas . I oczywiście nie pomaga to w tym, że nie ma gotowej, wygodnej metody prawidłowego odczytu dokładnie N bajtów.

Tak więc, aby zatkać dziurę i zwiększyć świadomość tego, oto przykład prawidłowego sposobu:

    /// <summary>
    /// Attempts to fill the buffer with the specified number of bytes from the
    /// stream. If there are fewer bytes left in the stream than requested then
    /// all available bytes will be read into the buffer.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="buffer">Buffer to write the bytes to.</param>
    /// <param name="offset">Offset at which to write the first byte read from
    ///                      the stream.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    /// <returns>Number of bytes read from the stream into buffer. This may be
    ///          less than requested, but only if the stream ended before the
    ///          required number of bytes were read.</returns>
    public static int FillBuffer(this Stream stream,
                                 byte[] buffer, int offset, int length)
    {
        int totalRead = 0;
        while (length > 0)
        {
            var read = stream.Read(buffer, offset, length);
            if (read == 0)
                return totalRead;
            offset += read;
            length -= read;
            totalRead += read;
        }
        return totalRead;
    }

    /// <summary>
    /// Attempts to read the specified number of bytes from the stream. If
    /// there are fewer bytes left before the end of the stream, a shorter
    /// (possibly empty) array is returned.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    public static byte[] Read(this Stream stream, int length)
    {
        byte[] buf = new byte[length];
        int read = stream.FillBuffer(buf, 0, length);
        if (read < length)
            Array.Resize(ref buf, read);
        return buf;
    }

Wydarzenia

Nigdy nie zrozumiałem, dlaczego wydarzenia są cechą językową. Są skomplikowane w użyciu: musisz sprawdzić, czy nie ma wartości zerowej przed dzwonieniem, musisz się wyrejestrować (sam), nie możesz dowiedzieć się, kto jest zarejestrowany (np. Czy się zarejestrowałem?). Dlaczego wydarzenie nie jest klasą w bibliotece? Zasadniczo specjalista List<delegate>?

Dzisiaj naprawiłem błąd, który wymknął się przez długi czas. Błąd występował w klasie ogólnej, która była używana w scenariuszu wielowątkowym, a do zapewnienia synchronizacji bez blokady za pomocą Interlocked zastosowano statyczne pole int. Błąd został spowodowany, ponieważ każda instancja klasy ogólnej dla typu ma własną statyczność. Więc każdy wątek ma swoje własne pole statyczne i nie był używany zamek zgodnie z przeznaczeniem.

class SomeGeneric<T>
{
    public static int i = 0;
}

class Test
{
    public static void main(string[] args)
    {
        SomeGeneric<int>.i = 5;
        SomeGeneric<string>.i = 10;
        Console.WriteLine(SomeGeneric<int>.i);
        Console.WriteLine(SomeGeneric<string>.i);
        Console.WriteLine(SomeGeneric<int>.i);
    }
}

Drukuje 5 10 5

Wyliczenia można oceniać więcej niż raz

Ugryzie cię, gdy będziesz miał leniwie wyliczony i powtórzysz go dwa razy i uzyskasz inne wyniki. (lub otrzymujesz te same wyniki, ale wykonuje się niepotrzebnie dwa razy)

Na przykład podczas pisania pewnego testu potrzebowałem kilku plików tymczasowych do przetestowania logiki:

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName());

foreach (var file in files)
    File.WriteAllText(file, "HELLO WORLD!");

/* ... many lines of codes later ... */

foreach (var file in files)
    File.Delete(file);

Wyobraź sobie moją niespodziankę, gdy File.Delete(file)rzuca FileNotFound!!

To, co się tutaj dzieje, polega na tym, że fileswyliczalność została powtórzona dwukrotnie (wyniki z pierwszej iteracji po prostu nie są zapamiętywane), a przy każdej nowej iteracji będziesz ponownie wywoływał, Path.GetTempFilename()aby uzyskać inny zestaw nazw plików tymczasowych.

Rozwiązaniem jest oczywiście wyliczenie wartości za pomocą ToArray()lub ToList():

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName())
    .ToArray();

Jest to jeszcze bardziej przerażające, gdy robisz coś wielowątkowego, na przykład:

foreach (var file in files)
    content = content + File.ReadAllText(file);

i okazuje się, że content.Lengthwciąż jest 0 po wszystkich zapisach !! Następnie zaczynasz rygorystycznie sprawdzać, czy nie masz warunków do wyścigu, gdy ... po jednej straconej godzinie ... zorientowałeś się, że to po prostu ta mała, wyliczalna rzecz, którą zapomniałeś ...

Właśnie znalazłem dziwny, w którym utknąłem na chwilę w debugowaniu:

Możesz zwiększyć wartość null dla wartości zerowej int bez rzucania wykroczenia, a wartość pozostanie null.

int? i = null;
i++; // I would have expected an exception but runs fine and stays as null

TextInfo textInfo = Thread.CurrentThread.CurrentCulture.TextInfo;

textInfo.ToTitleCase("hello world!"); //Returns "Hello World!"
textInfo.ToTitleCase("hElLo WoRld!"); //Returns "Hello World!"
textInfo.ToTitleCase("Hello World!"); //Returns "Hello World!"
textInfo.ToTitleCase("HELLO WORLD!"); //Returns "HELLO WORLD!"

Tak, to zachowanie jest udokumentowane, ale z pewnością nie jest to właściwe.