Mehrere häufige Fehler in C#/.NET

1 Ressourcen umgehend freigeben
Die CLR-Hostingumgebung übernimmt die Rolle der Garbage Collection, sodass Sie den von erstellten Objekten belegten Speicher nicht explizit freigeben müssen. Das heißt aber nicht, dass Sie alle verwendeten Objekte ignorieren können. Viele Objekte kapseln andere Arten von Systemressourcen (z. B. Festplattendateien, Datenverbindungen, Netzwerkports). Die Nutzung dieser Ressourcen kann die Systemressourcen drastisch belasten, die Leistung beeinträchtigen und letztendlich zu Programmfehlern führen. Wenn Sie eine Datei, einen Netzwerkport oder eine Datenverbindung öffnen, sollten Sie die Ressourcen explizit freigeben, sobald Sie sie nicht mehr verwenden.
Darüber hinaus ist es für Ressourcenoperationen im Allgemeinen erforderlich, eine Ausnahmeerfassungsverarbeitung (Try..Catch) hinzuzufügen. Vergessen Sie zu diesem Zeitpunkt nicht, die Ressource endgültig freizugeben, um sicherzustellen, dass die Ressource wann normal freigegeben werden kann die Ausnahme abfangen.
2 Multi-Threads korrekt stoppen
FileStream fs = File.Open(…);
Try{…} Endlich{ fs.Close;}
Angenommen, der obige Code befindet sich im Arbeitsthread und wurde zu „finally“ verarbeitet. Zu diesem Zeitpunkt ruft der UI-Thread die Abort()-Methode des Threads auf. Daher ist es sehr wahrscheinlich, dass der Arbeitsthread aus dem „finally“-Codeblock springt, bevor fs.Close ausgeführt wird. Auf diese Weise wird Ihr FS niemals geschlossen.
In den meisten Fällen wird „finally“ für immer ausgeführt, enthält jedoch keine ThreadAbortException, die durch den Aufruf von „Thread.Abort“ ausgelöst wird. Aus diesem Grund wird die Verwendung von „Abort“ nicht empfohlen.
Um einen Thread korrekt zu stoppen, kommt es nicht darauf an, welches Verhalten der Aufrufer annimmt (verwenden Sie Thread.Abort() nicht direkt), sondern vielmehr darauf, ob der Arbeitsthread aktiv auf die Stoppanforderung des Aufrufers reagieren kann.
Der allgemeine Mechanismus besteht darin, dass, wenn der Thread gestoppt werden muss, der Thread selbst dafür verantwortlich sein sollte, die Abbruchschnittstelle für den Aufrufer zu öffnen.
3 Typumwandlungsbezogen
Wenn ein Wert aus der Datenbank gelesen wird, ist er vom Typ int, wenn keine Daten vorhanden sind. Wenn der Typ erzwungen wird, wird eine Ausnahme ausgelöst geschehen. Daher wird die erzwungene Übertragung selten verwendet. Wenn sie verwendet wird, muss eine Ausnahme abgefangen werden, um Programmausnahmen zu vermeiden.
Für den Fall, dass die erzwungene Übertragung nicht funktioniert, empfehlen wir die Verwendung der TryParse-Methode, die bereits eine Ausnahmebehandlung für die Parse-Methode implementiert hat.
Sie können auch Convert verwenden, was auch das Abfangen von Ausnahmen erfordert. Tatsächlich müssen Ausnahmen überall dort abgefangen werden, wo es um Typkonvertierung, Serialisierung und andere Vorgänge geht.
4 String-Operationsprobleme
Bei String-Operationen, wenn Da eine große Anzahl von Spleißvorgängen erforderlich ist, wird die Verwendung von StringBuilder empfohlen. Wenn Sie String verwenden, kommt es zu offensichtlichen Leistungseinbußen. Der Grund dafür ist, dass das String-Objekt ein ganz besonderes Objekt ist und nicht mehr geändert werden kann, sobald ihm ein Wert zugewiesen wurde. Durch den Aufruf einer Spleißoperation (z. B. Zuweisung, „+“ usw.) in der String-Klasse zur Laufzeit wird ein neues String-Objekt im Speicher erstellt, was auch bedeutet, dass dem neuen Objekt neuer Speicherplatz zugewiesen werden muss.
5 Probleme, die durch die Änderung der Konstantenkonstante verursacht werden
Achten Sie besonders darauf, wenn das Programm auf Konstantenkonstanten in anderen DLLs verweist.
Wenn Sie die Konstante const in dieser DLL ändern, müssen Sie alle Programme neu kompilieren, die auf diese Konstante const in dieser DLL verweisen, da sonst der im Programm verwendete Konstantenwert nicht mit dem Wert in der DLL übereinstimmt.
Wenn Sie außerdem readonly anstelle von const verwenden, können Sie dieses Problem ohne Neukompilierung lösen, da const eine kompilierte Konstante und readonly eine Laufzeitkonstante ist.
6 Probleme mit der C#-Kompilierungszielplattform
Wenn die DLL, von der das Programm abhängt, auf eine Zielplattform von X86 kompiliert wird, muss die Kompilierungszielplattform des Programms selbst auch nicht ausgeführt werden können.
7 Thread-übergreifende Zugriffskontrolle
Bei der Entwicklung von Schnittstellenprogrammen treten zeitaufwändige Vorgänge auf. Aus Gründen der Benutzerfreundlichkeit führen wir im Allgemeinen zeitaufwändige Vorgänge im Task-Thread aus und zeigen die Ausführungsinformationen in Main an UI-Thread.
Wenn Sie die Steuerelemente direkt im Haupt-UI-Thread im Aufgabenthread bedienen, kann es sehr leicht zu einer Ausnahme kommen und melden, dass „der Wert des Threads, der das Steuerelement erstellt hat, in anderen Threads nicht geändert werden kann“. Wenn Sie festlegen, dass der Compiler den Cross-Thread-Zugriff nicht überprüfen kann, wird kein Fehler gemeldet, es treten jedoch unvorhersehbare Probleme auf. Zu diesem Zeitpunkt wird empfohlen, die Delegation oder die anonyme Delegation zu verwenden.

Das obige ist der detaillierte Inhalt vonMehrere häufige Fehler in C#/.NET. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!