Recentemente stavo lavorando con un DateTimeoggetto e ho scritto qualcosa del genere:

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

La documentazione di intellisense per AddDays()dice che aggiunge un giorno alla data, che non lo fa - in realtà restituisce una data con un giorno aggiunto ad essa, quindi devi scriverla come:

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

Questo mi ha morso un numero di volte prima, quindi ho pensato che sarebbe stato utile catalogare i peggiori C # gotchas.

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

Blammo. L'app si arresta in modo anomalo senza traccia dello stack. Succede tutte le volte.

(Nota maiuscola MyVaranziché minuscolamyVar nel getter.)

Type.GetType

Quello che ho visto mordere molte persone è Type.GetType(string). Si chiedono perché funzioni per i tipi nel proprio assemblaggio e alcuni tipi come System.String, ma non System.Windows.Forms.Form. La risposta è che appare solo nell'assieme corrente e dentro mscorlib.

Metodi anonimi

C # 2.0 ha introdotto metodi anonimi, portando a brutte situazioni come questa:

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();
        }
    }
}

Cosa verrà stampato? Bene, dipende interamente dalla programmazione. Stampa 10 numeri, ma probabilmente non stampa 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, che è quello che ti aspetteresti. Il problema è che iè stata acquisita la variabile, non il suo valore nel punto in cui è stato creato il delegato. Questo può essere risolto facilmente con una variabile locale aggiuntiva del giusto ambito:

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();
        }
    }
}

Esecuzione differita di blocchi iteratori

Questo "test unitario dei poveri" non passa - perché no?

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
        }
    }
}

La risposta è che il codice all'interno della sorgente del CapitalLetterscodice non viene eseguito fino all'iteratoreMoveNext() viene chiamato per la prima volta metodo .

Ho altre stranezze nella pagina dei miei rompicapo .

Ri-lanciare eccezioni

Un gotcha che ottiene molti nuovi sviluppatori, è la semantica dell'eccezione del re-lancio.

Un sacco di tempo vedo codice come il seguente

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

Il problema è che cancella la traccia dello stack e rende molto più difficile la diagnosi dei problemi, poiché non è possibile tenere traccia dell'origine dell'eccezione.

Il codice corretto è l'istruzione throw senza argomenti:

catch(Exception)
{
    throw;
}

O racchiudendo l'eccezione in un'altra e usando l'eccezione interna per ottenere la traccia dello stack originale:

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

La finestra di Heisenberg

Questo può morderti male se stai facendo cose load-on-demand, come questo:

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

Ora supponiamo che tu abbia del codice altrove usando questo:

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

Ora vuoi eseguire il debug del tuo CreateMyObj()metodo. Quindi metti un punto di interruzione sulla riga 3 sopra, con l'intenzione di entrare nel codice. Solo per una buona misura, hai anche messo un breakpoint sulla linea sopra che dice _myObj = CreateMyObj();, e persino un breakpoint dentro di CreateMyObj()sé.

Il codice raggiunge il punto di interruzione sulla riga 3. Si entra nel codice. Ti aspetti di inserire il codice condizionale, perché _myObjovviamente è nullo, giusto? Uh ... quindi ... perché ha saltato la condizione ed è andato dritto a return _myObj?! Passa il mouse sopra _myObj ... e in effetti ha un valore! Come è successo?!

La risposta è che il tuo IDE gli ha fatto ottenere un valore, perché hai una finestra "watch" aperta, in particolare la finestra "Autos", che mostra i valori di tutte le variabili / proprietà rilevanti per la linea di esecuzione corrente o precedente. Quando raggiungi il tuo punto di interruzione sulla Linea 3, la finestra dell'orologio ha deciso che ti sarebbe interessato conoscere il valore di MyObj- quindi dietro le quinte, ignorando qualsiasi tuo punto di interruzione , è andato e ha calcolato il valore MyObjper te - inclusa la chiamata a CreateMyObj()quella imposta il valore di _myObj!

Ecco perché la chiamo Heisenberg Watch Window: non puoi osservare il valore senza influenzarlo ... :)

GOTCHA!

modificare - Sento che il commento di @ ChristianHayter merita l'inclusione nella risposta principale, perché sembra una soluzione efficace per questo problema. Quindi ogni volta che hai una proprietà pigra ...

Decorare la proprietà con [DebuggerBrowsable (DebuggerBrowsableState.Never)] o [DebuggerDisplay ("<caricato su richiesta>")]. - Christian Hayter

Ecco un'altra volta che mi prende:

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

TimeSpan.Seconds è la porzione di secondi dell'intervallo di tempo (2 minuti e 0 secondi ha un valore di secondi pari a 0).

TimeSpan.TotalSeconds è l'intero intervallo di tempo misurato in secondi (2 minuti ha un valore di secondi totali di 120).

Perdita di memoria perché non hai sganciato gli eventi.

Questo ha persino catturato alcuni sviluppatori senior che conosco.

Immagina un modulo WPF con molte cose al suo interno e da qualche parte lì ti iscrivi a un evento. Se non si annulla l'iscrizione, l'intero modulo viene mantenuto in memoria dopo essere stato chiuso e de-referenziato.

Credo che il problema che ho riscontrato sia stato la creazione di un DispatchTimer nel modulo WPF e l'iscrizione all'evento Tick, se non si esegue un - = sul timer il modulo perde memoria!

In questo esempio il tuo codice di smontaggio dovrebbe avere

timer.Tick -= TimerTickEventHandler;

Questo è particolarmente complicato da quando hai creato l'istanza di DispatchTimer all'interno del modulo WPF, quindi potresti pensare che sarebbe un riferimento interno gestito dal processo Garbage Collection ... sfortunatamente DispatchTimer utilizza un elenco interno statico di abbonamenti e servizi richieste sul thread dell'interfaccia utente, quindi il riferimento è "posseduto" dalla classe statica.

Forse non è proprio un gotcha perché il comportamento è scritto chiaramente in MSDN, ma una volta mi è rotto il collo perché l'ho trovato piuttosto intuitivo:

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

Questo ragazzo lascia il "nice.pic" file bloccato fino a quando l'immagine non viene eliminata. Al momento l'ho affrontato, anche se sarebbe stato bello caricare le icone al volo e non mi ero reso conto (all'inizio) che avevo finito con decine di file aperti e bloccati! L'immagine tiene traccia di dove aveva caricato il file da ...

Come risolverlo? Ho pensato che una fodera avrebbe fatto il lavoro. Mi aspettavo un parametro aggiuntivo per FromFile(), ma non ne avevo, quindi ho scritto questo ...

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

Se conti ASP.NET, direi che il ciclo di vita dei moduli web è un grosso problema per me. Ho trascorso innumerevoli ore a eseguire il debug di codici di moduli web scritti male, solo perché molti sviluppatori non capiscono davvero quando utilizzare quale gestore di eventi (me incluso, purtroppo).

sovraccaricato == operatori e contenitori non tipizzati (array, set di dati, ecc.):

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

Soluzioni?

• utilizzare sempre string.Equals(a, b)quando si confrontano i tipi di stringa

• usare generici come List<string>per assicurarsi che entrambi gli operandi siano stringhe.

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

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

Morale della storia: gli inizializzatori di campo non vengono eseguiti durante la deserializzazione di un oggetto

DateTime.ToString ("gg / MM / aaaa") ; Questo in realtà non ti darà sempre gg / MM / aaaa, ma prenderà in considerazione le impostazioni regionali e sostituirà il separatore di date a seconda di dove ti trovi. Quindi potresti ottenere gg-MM-aaaa o qualcosa di simile.

Il modo giusto per farlo è usare DateTime.ToString ("dd '/' MM '/' yyyy");

DateTime.ToString ("r") dovrebbe essere convertito in RFC1123, che utilizza GMT. GMT è a una frazione di secondo da UTC, eppure l'identificatore di formato "r" non viene convertito in UTC , anche se DateTime in questione è specificato come Locale.

Ciò si traduce nel seguente gotcha (varia in base alla distanza dell'ora locale da UTC):

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

Ops!

L'ho visto pubblicato l'altro giorno e penso che sia piuttosto oscuro e doloroso per coloro che non lo sanno

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

Poiché ciò restituirà 0 e non 1 come la maggior parte si aspetterebbe

Sono un po 'in ritardo per questa festa, ma ho due gotcha che mi hanno morso di recente:

Risoluzione DateTime

La proprietà Ticks misura il tempo in 10 milionesimi di secondo (100 blocchi di nanosecondi), tuttavia la risoluzione non è di 100 nanosecondi, è di circa 15ms.

Questo codice:

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

ti darà un output di (ad esempio):

0
0
0
0
0
0
0
156254
156254
156254

Allo stesso modo, se guardi DateTime.Now.Millisecond, otterrai valori in blocchi arrotondati di 15,625 ms: 15, 31, 46, ecc.

Questo comportamento particolare varia da sistema a sistema , ma ci sono altri gotcha relativi alla risoluzione in questa API data / ora.

Path.Combine

Un ottimo modo per combinare i percorsi dei file, ma non si comporta sempre come previsto.

Se il secondo parametro inizia con un \carattere, non ti darà un percorso completo:

Questo codice:

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));

Ti dà questo risultato:

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

Quando avvii un processo (usando System.Diagnostics) che scrive sulla console, ma non leggi mai la Console. Fuori flusso, dopo una certa quantità di output la tua app sembrerà bloccarsi.

Nessuna scorciatoia operatore in Linq-To-Sql

Vedi qui .

In breve, all'interno della clausola condizionale di una query Linq-To-Sql, non è possibile utilizzare scorciatoie condizionali come ||ed &&evitare eccezioni di riferimento null; Linq-To-Sql valuta entrambi i lati dell'operatore OR o AND anche se la prima condizione ovvia alla necessità di valutare la seconda condizione!

Utilizzo dei parametri predefiniti con metodi virtuali

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();

Uscita:
base derivata

Valore oggetti in raccolte mutabili

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

mypoints[i].x = 10;

non ha alcun effetto.

mypoints[i]restituisce una copia di un Pointoggetto valore. C # consente felicemente di modificare un campo della copia. Non fare nulla in silenzio.

Aggiornamento: questo sembra essere corretto in C # 3.0:

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

Forse non il peggio, ma alcune parti del framework .net usano gradi mentre altri usano i radianti (e la documentazione che appare con Intellisense non ti dice mai quale, devi visitare MSDN per scoprirlo)

Tutto ciò avrebbe potuto essere evitato con una Angleclasse invece ...

Per i programmatori C / C ++, la transizione a C # è naturale. Tuttavia, il più grande gotcha che ho incontrato personalmente (e ho visto con gli altri fare la stessa transizione) non è comprendere appieno la differenza tra classi e strutture in C #.

In C ++, le classi e le strutture sono identiche; differiscono solo per la visibilità predefinita, dove le classi passano automaticamente alla visibilità privata e le strutture predefinite per la visibilità pubblica. In C ++, questa definizione di classe

    class A
    {
    public:
        int i;
    };

è funzionalmente equivalente a questa definizione di struttura.

    struct A
    {
        int i;
    };

In C #, tuttavia, le classi sono tipi di riferimento mentre le strutture sono tipi di valore. Questo fa una GRANDE differenza nel (1) decidere quando usare l'uno sull'altro, (2) testare l'uguaglianza degli oggetti, (3) le prestazioni (es. Boxe / unboxing), ecc.

Ci sono tutti i tipi di informazioni sul web relative alle differenze tra i due (ad esempio, qui ). Incoraggerei vivamente chiunque effettui il passaggio a C # per avere almeno una conoscenza pratica delle differenze e delle loro implicazioni.

Garbage collection e Dispose (). Anche se non devi fare nulla per liberare memoria , devi comunque liberare risorse tramite Dispose (). Questa è una cosa immensamente facile da dimenticare quando si utilizza WinForms o si tracciano oggetti in qualsiasi modo.

Implementazione di array IList

Ma non implementarlo. Quando chiami Aggiungi, ti dice che non funziona. Quindi perché una classe implementa un'interfaccia quando non può supportarla?

Compila, ma non funziona:

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

Abbiamo questo problema molto, perché il serializzatore (WCF) trasforma tutti gli IList in array e otteniamo errori di runtime.

foreach loops variabili scope!

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());

stampa cinque "amet", mentre l'esempio seguente funziona bene

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 non è in grado di gestire date precedenti al 1753. Significativamente, non è sincronizzato con la DateTime.MinDatecostante .NET , che è 1/1/1. Quindi, se provi a salvare una mentalità, una data non valida (come mi è successo di recente in un'importazione di dati) o semplicemente la data di nascita di William the Conqueror, avrai dei problemi. Non esiste una soluzione alternativa per questo; se è probabile che tu debba lavorare con date precedenti al 1753, devi scrivere la tua soluzione alternativa.

La cattiva cache di Linq Gotcha

Vedi la mia domanda che ha portato a questa scoperta e al blogger che ha scoperto il problema.

In breve, DataContext mantiene una cache di tutti gli oggetti Linq-to-Sql che tu abbia mai caricato. Se qualcun altro apporta delle modifiche a un record che hai precedentemente caricato, non sarai in grado di ottenere i dati più recenti, anche se ricarichi esplicitamente il record!

Ciò è dovuto a una proprietà chiamata ObjectTrackingEnabledsu DataContext, che per impostazione predefinita è vera. Se imposti tale proprietà su false, il record verrà caricato di nuovo ogni volta ... MA ... non puoi persistere alcuna modifica a quel record con SubmitChanges ().

GOTCHA!

Il contratto su Stream.Read è qualcosa che ho visto inciampare in molte persone:

// 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);

Il motivo per cui questo è sbagliato è che Stream.Readleggerà al massimo il numero specificato di byte, ma è completamente gratuito per leggere solo 1 byte, anche se sono disponibili altri 7 byte prima della fine dello stream.

Non aiuta che sia così simile a Stream.Write, che è garantito per aver scritto tutti i byte se ritorna senza eccezioni. Inoltre, non aiuta il fatto che il codice sopra riportato funzioni quasi sempre . E ovviamente non aiuta che non esista un metodo pronto e conveniente per leggere correttamente esattamente N byte.

Quindi, per tappare il buco e aumentare la consapevolezza di questo, ecco un esempio di un modo corretto per farlo:

    /// <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;
    }

eventi

Non ho mai capito perché gli eventi siano una caratteristica linguistica. Sono complicati da usare: è necessario verificare la presenza di null prima di chiamare, è necessario annullare la registrazione (se stessi), non è possibile scoprire chi è registrato (ad esempio: mi sono registrato?). Perché un evento non è solo una lezione in biblioteca? Fondamentalmente uno specialista List<delegate>?

Oggi ho corretto un bug che è sfuggito a lungo. Il bug era in una classe generica che veniva utilizzata in uno scenario multi-thread e un campo int statico veniva utilizzato per fornire la sincronizzazione senza blocco tramite Interlocked. Il bug è stato causato perché ogni istanza della classe generica per un tipo ha il suo statico. Quindi ogni thread ha il suo campo statico e non è stato usato un blocco come previsto.

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);
    }
}

Questo stampa 5 10 5

Gli enumerabili possono essere valutati più di una volta

Ti morderà quando hai un elenco numerato pigramente e ci provi due volte e ottieni risultati diversi. (o ottieni gli stessi risultati ma viene eseguito due volte inutilmente)

Ad esempio, mentre scrivevo un certo test, avevo bisogno di alcuni file temporanei per testare la logica:

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);

Immagina la mia sorpresa quando File.Delete(file)lancia FileNotFound!!

Quello che sta succedendo qui è che l' filesenumerabile è stato ripetuto due volte (i risultati della prima iterazione semplicemente non lo sono ricordati) e su ogni nuova iterazione che verrai richiamato in Path.GetTempFilename()modo da ottenere un diverso set di nomi di file temporanei.

La soluzione è, ovviamente, quella di enumerare il valore utilizzando ToArray()o ToList():

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

Questo è ancora più spaventoso quando stai facendo qualcosa di multi-thread, come:

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

e scopri che content.Lengthè ancora 0 dopo tutte le scritture !! Quindi inizi a controllare rigorosamente che non hai una condizione di gara quando ... dopo un'ora sprecata ... hai capito che è solo quella piccola cosa enumerabile che hai dimenticato ...

Ne ho appena trovato uno strano che mi ha bloccato per un po 'nel debug:

È possibile incrementare null per un int nullable senza lanciare un'eccitazione e il valore rimane nullo.

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!"

Sì, questo comportamento è documentato, ma certamente non lo rende giusto.