Best Practices für die Ausnahmebehandlung in .NET (übersetzt)

Ursprüngliche Adresse: Klicken Sie hier, um den Link zu öffnen

Dieser Artikel wurde aus einem übersetzt Artikel über CodeProject Artikel, Originaladresse.

Inhaltsverzeichnis

• Einleitung

• Seien Sie auf das Schlimmste vorbereitet

• Überprüfen Sie im Voraus

• Vertraue externen Daten nicht

• Vertrauenswürdige Geräte: Kamera, Maus und Tastatur

• „Schreibvorgang“ kann ebenfalls fehlschlagen

• Sichere Programmierung

• Keine „neue Ausnahme()“ auslösen

• Speichern Sie keine wichtigen Ausnahmeinformationen in der Message-Eigenschaft

• Jeder Thread sollte einen Try/Catch-Block enthalten

• Nachdem Sie die Ausnahme abgefangen haben, zeichnen Sie sie auf

• Notieren Sie nicht nur den Wert von Exception.Message, sondern auch Exception.ToString()

• Um die spezifischen Ausnahmen zu erfassen

• Auslösen von Ausnahmen nicht abbrechen

• Bereinigung Code sollte im „finally“-Block platziert werden

• Vergessen Sie nicht, using zu verwenden

• Verwenden Sie keine speziellen Rückgabewerte, um anzugeben, was in der Methode Exception passiert ist

• Verwenden Sie nicht die Methode „Ausnahme auslösen“, um anzugeben, dass die Ressource existiert nicht

• Verwenden Sie „Auslösen einer Ausnahme“ nicht als Ergebnis der Funktionsausführung

• Sie können die Methode „auslösende Ausnahme“ verwenden, um hervorzuheben, was nicht ignoriert werden kann. Fehler

• Stack-Trace-Informationen nicht löschen

• Ausnahmeklasse sollte als serialisierbar markiert sein

• Verwenden Sie „Throw Exception“ anstelle von Debug.Assert

• pro Eine Ausnahmeklasse enthält mindestens drei Konstruktoren

• Erfinden Sie das Rad nicht neu

• VB.NET

• Simulieren Sie die using-Anweisung in C#

• Keine unstrukturierte Ausnahmebehandlung verwenden (Bei Fehler gehe zu) 🎜>Einführung

• „Mein „Softwareprogramme gehen nie schief.“ Glaubst du es? Ich bin mir fast sicher, dass jeder schreien wird, ich sei ein Lügner. „Es ist fast unmöglich, dass ein Softwareprogramm fehlerfrei ist!“

Tatsächlich ist es nicht unmöglich, ein vertrauenswürdiges und solides Softwareprogramm zu entwickeln. Beachten Sie, dass ich mich nicht auf die zur Steuerung von Kernkraftwerken verwendete Software beziehe, sondern auf einige gängige kommerzielle Software, die auf Servern oder PCs laufen kann. Es kann ein großes Problem auftreten. Wie Sie sich denken können, meinte ich gerade, dass die Software eine relativ niedrige Fehlerquote hat, man die Fehlerursache schnell finden und schnell beheben kann und die Fehler keinen größeren Datenschaden verursachen.

Mit anderen Worten, ich meine, dass die Software relativ stabil ist.

Es ist verständlich, dass es Fehler in der Software gibt. Aber wenn es sich um einen wiederkehrenden Fehler handelt und Sie ihn nicht schnell beheben können, weil nicht genügend Informationen vorhanden sind, ist das unverzeihlich.

Um besser zu verstehen, was ich oben gesagt habe, möchte ich Ihnen ein Beispiel geben: Ich sehe oft unzählige kommerzielle Software, die diese Fehlermeldung ausgibt, wenn die Festplatte nicht ausreicht:

„Kundeninformationen konnten nicht aktualisiert werden. Bitte wenden Sie sich an den Systemadministrator und versuchen Sie es erneut.“

Darüber hinaus werden keine weiteren Informationen erfasst. Es ist ein sehr zeitaufwändiger Prozess, die Ursache dieses Fehlers herauszufinden. Möglicherweise müssen Programmierer verschiedene Vermutungen anstellen, bevor sie die Ursache des Problems tatsächlich finden.

Beachten Sie, dass ich in diesem Artikel hauptsächlich darüber spreche, wie Ausnahmen in der .NET-Programmierung besser behandelt werden können. Ich habe nicht vor, darauf einzugehen, wie entsprechende „Fehlermeldungen“ angezeigt werden, da ich denke, dass dieser Job zur UI-Schnittstelle gehört .Entwickler, und es hängt hauptsächlich von der Art der Benutzeroberfläche ab und davon, wer die Software letztendlich verwenden wird. Beispielsweise sollte die „Fehlermeldung“ eines Texteditors für normale Benutzer völlig anders sein als die eines Socket-Kommunikationsframeworks, da dessen direkte Benutzer Programmierer sind.

Seien Sie auf das Schlimmste vorbereitet

Befolgen Sie einige Grundlagen Designprinzipien können Ihr Programm robuster machen und das Benutzererlebnis verbessern, wenn Fehler auftreten. Die „Verbesserung der Benutzererfahrung“, von der ich hier spreche, bedeutet nicht, dass das Fehleraufforderungsformular Benutzer glücklich machen kann, sondern dass auftretende Fehler nicht die Originaldaten beschädigen oder den gesamten Computer zum Absturz bringen. Wenn Ihr Programm auf einen Fehler aufgrund einer unzureichenden Festplatte stößt, das Programm jedoch keine anderen negativen Auswirkungen verursacht (es löst nur eine Fehlermeldung aus und verursacht keine anderen Probleme, Anmerkung des Übersetzers), verbessert sich die Benutzererfahrung.

• Überprüfen Sie im Voraus

Eine starke Typprüfung und -validierung ist möglich Eine wirksame Möglichkeit, Fehler zu vermeiden. Je früher Sie ein Problem erkennen, desto schneller können Sie es beheben. Es ist nicht einfach und ziemlich ärgerlich, nach ein paar Monaten herauszufinden: „Warum gibt es in der Spalte „ProductID“ der Tabelle „InvoiceItems“ CustomerID-Daten? Wenn Sie zum Speichern von Kundendaten eine Klasse anstelle von Basistypen (z. B. int, string) verwenden, lässt der Compiler nicht zu, dass das passiert, was gerade passiert ist (bezieht sich auf die Verwechslung von CustomerID und ProductID, Anmerkung des Übersetzers).

• Vertrauen Sie externen Daten nicht

Externe Daten nicht zuverlässig ist, müssen unsere Softwareprogramme vor der Verwendung gründlich überprüft werden. Unabhängig davon, ob diese externen Daten aus der Registry, der Datenbank, der Festplatte, dem Socket oder von Ihnen über die Tastatur geschriebenen Dateien stammen, müssen alle diese externen Daten vor der Verwendung streng überprüft werden. Ich sehe oft Programme, die der Konfigurationsdatei völlig vertrauen, weil die Programmierer, die diese Programme entwickeln, immer davon ausgehen, dass niemand die Konfigurationsdatei bearbeiten und beschädigen wird.

• Vertrauenswürdige Geräte: Kamera, Maus und Tastatur

Wenn Sie externe Daten verwenden müssen, können die folgenden Situationen auftreten:

　1) Unzureichende Sicherheitsberechtigungen

2) Die Daten funktionieren nicht existieren

　3) Die Daten sind unvollständig

　4) Die Daten sind vollständig, aber das Format ist falsch

Die obige Situation kann unabhängig davon auftreten, ob die Datenquelle ein Schlüssel in der Registrierung, eine Datei, ein Socket, eine Datenbank, ein Webdienst oder ein serieller Port ist. Alle externen Daten unterliegen dem Fehler.

• "Schreibvorgang" kann ebenfalls fehlschlagen

Nicht verfügbar Eine vertrauenswürdige Datenquelle ist auch ein nicht vertrauenswürdiges Data Warehouse. Wenn Sie Daten speichern, können immer noch ähnliche Situationen auftreten:

　1) Unzureichende Sicherheitsberechtigungen

　2) Das Gerät existiert nicht

　3) Nicht genügend Speicherplatz

　4) Im Speichergerät ist ein physischer Fehler aufgetreten

Dies Dies Aus diesem Grund erstellen einige Komprimierungsprogramme während der Arbeit eine temporäre Datei und benennen sie nach Abschluss der Arbeit um, anstatt die Quelldatei direkt zu ändern. Der Grund dafür ist, dass die Originaldaten verloren gehen können, wenn die Festplatte beschädigt ist (oder die Software nicht ordnungsgemäß funktioniert). (Der Übersetzer ist auf diese Situation gestoßen. Beim Sichern der Daten kam es zu einem Stromausfall und die ursprüngliche alte Sicherung wurde beschädigt. Anmerkung des Übersetzers)

Sicheres Programmieren

Ein Freund von mir sagte mir: Ein guter Programmierer schreibt niemals schlechten Code in sein Programm. Ich denke, das ist eine notwendige, aber keine hinreichende Voraussetzung, um ein guter Programmierer zu sein. Unten habe ich einige „schlechte Codes“ zusammengestellt, die Sie bei der Ausnahmebehandlung schreiben könnten:

• Don't throw „new Exception()“

Bitte tun Sie dies nicht. Exception ist eine sehr abstrakte Ausnahmeklasse. Das Abfangen dieser Art von Ausnahme hat normalerweise viele negative Auswirkungen. Normalerweise sollten wir unsere eigenen Ausnahmeklassen definieren und zwischen vom System (Framework) ausgelösten Ausnahmen und von uns selbst ausgelösten Ausnahmen unterscheiden.

• Speichern Sie keine wichtigen Ausnahmeinformationen in der Message-Eigenschaft

Ausnahmen werden in Klassen gekapselt. Wenn Sie Ausnahmeinformationen zurückgeben müssen, speichern Sie die Informationen bitte in einigen separaten Eigenschaften (nicht in der Message-Eigenschaft), da es sonst für Benutzer schwierig wird, die benötigten Informationen aus der Message-Eigenschaft zu analysieren. Wenn Sie beispielsweise nur einen Rechtschreibfehler korrigieren müssen und die Fehlermeldung und andere Eingabeaufforderungsinhalte in Form eines Strings in die Message-Eigenschaft schreiben, wie können andere dann einfach die gewünschte Fehlermeldung erhalten? Sie können sich nicht vorstellen, wie viel Aufwand sie betreiben müssen.

• Jeder Thread sollte einen Try/Catch-Block enthalten

Im Allgemeinen ist die Ausnahmebehandlung an einer relativ zentralen Stelle im Programm platziert. Jeder Thread muss über einen Try/Catch-Block verfügen, sonst verpassen Sie einige Ausnahmen und verursachen schwer verständliche Probleme. Wenn ein Programm mehrere Threads startet, um Hintergrundaufgaben zu erledigen, erstellen Sie normalerweise einen Typ, um die Ergebnisse der Ausführung jedes Threads zu speichern. Vergessen Sie zu diesem Zeitpunkt bitte nicht, dem Typ ein Feld hinzuzufügen, um die Ausnahmen zu speichern, die in jedem Thread auftreten können. Andernfalls kennt der Hauptthread die Ausnahmen anderer Threads nicht. In einigen „Fire and Forget“-Situationen (was bedeutet, dass sich der Hauptthread nach dem Starten des Threads nicht mehr um den laufenden Status des Threads kümmert, Anmerkung des Übersetzers) müssen Sie möglicherweise die Ausnahmebehandlungslogik im Hauptthread in Ihren untergeordneten Thread kopieren . gehen.

• Zeichnen Sie die Ausnahme auf, nachdem Sie sie abgefangen haben

Egal Es spielt keine Rolle, welche Methode Ihr Programm zum Aufzeichnen von Protokollen verwendet – log4net, EIF, Ereignisprotokoll, TraceListeners oder Textdateien. Wichtig ist: Wenn Sie auf eine Ausnahme stoßen, sollten Sie diese irgendwo protokollieren. Loggen Sie sich aber bitte nur einmal ein, sonst erhalten Sie am Ende eine sehr große Protokolldatei mit vielen sich wiederholenden Informationen.

• Notieren Sie nicht nur den Wert von Exception.Message, sondern auch Exception.ToString()

Wenn wir über Protokollierung sprechen, vergessen Sie nicht, dass wir den Wert von Exception.ToString() protokollieren sollten, nicht Exception.Message. Weil Exception.ToString() „Stack-Trace“-Informationen, interne Ausnahmeinformationen und Nachrichten enthält. Normalerweise sind diese Informationen sehr wichtig, und wenn Sie nur Exception.Message protokollieren, wird möglicherweise nur eine Eingabeaufforderung wie „Objektreferenz zeigt nicht auf eine Instanz im Heap“ angezeigt.

• Um bestimmte Ausnahmen abzufangen

Wenn Sie möchten Ausnahmen abfangen, versuchen Sie bitte so oft wie möglich bestimmte Ausnahmen (keine Ausnahmen) abzufangen.

Ich sehe Anfänger oft sagen, dass ein guter Code Code ist, der keine Ausnahmen auslösen kann. Tatsächlich ist diese Aussage falsch. Guter Code sollte bei Bedarf entsprechende Ausnahmen auslösen, und guter Code kann nur Ausnahmen abfangen, mit denen er umgehen kann (beachten Sie diesen Satz, Anmerkung des Übersetzers).

Der folgende Code dient als Erläuterung dieser Regel. Ich wette, der Typ, der den folgenden Code geschrieben hat, würde mich umbringen, wenn er ihn sehen würde, aber es ist ein Codestück, das aus einem echten Programmierjob stammt.

Die erste Klasse MyClass befindet sich in einer Assembly und die zweite Klasse GenericLibrary befindet sich in einer anderen Assembly. Es läuft normal auf dem Entwicklungscomputer, aber auf dem Testcomputer wird immer die Ausnahme „Ungültige Daten!“ ausgelöst, obwohl die eingegebenen Daten jedes Mal zulässig sind.

Können Sie mir sagen, warum?

public class MyClass
{
    public static string ValidateNumber(string userInput)
    {
        try
        {
            int val = GenericLibrary.ConvertToInt(userInput);
            return "Valid number";
        }
        catch (Exception)
        {
            return "Invalid number";
        }
    }
}

public class GenericLibrary
{
    public static int ConvertToInt(string userInput)
    {
        return Convert.ToInt32(userInput);
    }
}

Der Grund für dieses Problem ist, dass die Ausnahmebehandlung nicht sehr spezifisch ist. Laut der Einführung auf MSDN löst die Convert.ToInt32-Methode nur drei Ausnahmen aus: ArgumentException, FormatException und OverflowException. Daher sollten wir nur diese drei Ausnahmen behandeln.

问题发生在我们程序安装的步骤上，我们没有将第二个程序集（GenericLibrary.dll）打包进去。所以程序运行后，ConvertToInt方法会抛出FileNotFoundException异常，但是我们捕获的异常是Exception，所以会提示“数据不合法”。

• 不要中止异常上抛

最坏的情况是，你编写catch(Exception)这样的代码，并且在catch块中啥也不干。请不要这样做。

• 清理代码要放在finally块中

大多数时候，我们只处理某一些特定的异常，其它异常不负责处理。那么我们的代码中就应该多一些finally块（就算发生了不处理的异常，也可以在finally块中做一些事情，译者注），比如清理资源的代码、关闭流或者回复状态等。请把这当作习惯。

有一件大家容易忽略的事情是：怎样让我们的try/catch块同时具备易读性和健壮性。举个例子，假设你需要从一个临时文件中读取数据并且返回一个字符串。无论什么情况发生，我们都得删除这个临时文件，因为它是临时性的。

让我们先看看最简单的不使用try/catch块的代码：

string ReadTempFile(string FileName)
{
    string fileContents;
    using (StreamReader sr = new StreamReader(FileName))
    {
        fileContents = sr.ReadToEnd();
    }
    File.Delete(FileName);
    return fileContents;
}

这段代码有一个问题，ReadToEnd方法有可能抛出异常，那么临时文件就无法删除了。所以有些人修改代码为：

string ReadTempFile(string FileName)
{
    try
    {
        string fileContents;
        using (StreamReader sr = new StreamReader(FileName))
        {
            fileContents = sr.ReadToEnd();
        }
        File.Delete(FileName);
        return fileContents;
    }
    catch (Exception)
    {
        File.Delete(FileName);
        throw;
    }
}

这段代码变得复杂一些，并且它包含了重复性的代码。

那么现在让我们看看更简介更健壮的使用try/finally的方式：

string ReadTempFile(string FileName)
{
    try
    {
        string fileContents;
        using (StreamReader sr = new StreamReader(FileName))
        {
            fileContents = sr.ReadToEnd();
        }
        File.Delete(FileName);
        return fileContents;
    }
    catch (Exception)
    {
        File.Delete(FileName);
        throw;
    }
}

变量fileContents去哪里了？它不再需要了，因为返回点在清理代码前面。这是让代码在方法返回后才执行的好处：你可以清理那些返回语句需要用到的资源（方法返回时需要用到的资源，所以资源只能在方法返回后才能释放，译者注）。

• 不要忘记使用using

仅仅调用对象的Dispose()方法是不够的。即使异常发生时，using关键字也能够防止资源泄漏。（关于对象的Dispose()方法的用法，可以关注我的书，有一章专门介绍。译者注）

• 不要使用特殊返回值去表示方法中发生的异常

因为这样做有很多问题：

　　1）直接抛出异常更快，因为使用特殊的返回值表示异常时，我们每次调用完方法时，都需要去检查返回结果，并且这至少要多占用一个寄存器。降低代码运行速度。

　　2）特殊返回值能，并且很可能被忽略

　　3）特殊返回值不能包含堆栈跟踪（stack trace）信息，不能返回异常的详细信息

　　4）很多时候，不存在一个特殊值去表示方法中发生的异常，比如，除数为零的情况：

public int pide(int x, int y)
{
    return x / y;
}

• 不要使用“抛出异常”的方式去表示资源不存在

微软建议在某些特定场合，方法可以通过返回一些特定值来表示方法在执行过程中发生了预计之外的事情。我知道我上面提到的规则恰恰跟这条建议相反，我也不喜欢这样搞。但是一些API确实使用了某些特殊返回值来表示方法中的异常，并且工作得很好，所以我还是觉得你们可以谨慎地遵循这条建议。

我看到了.NET Framework中很多获取资源的API方法使用了特殊返回值，比如Assembly.GetManifestStream方法，当找不到资源时（异常），它会返回null（不会抛出异常）。

• 不要将“抛出异常”作为函数执行结果的一种

这是一个非常糟糕的设计。代码中包含太多的try/catch块会使代码难以理解，恰当的设计完全可以满足一个方法返回各种不同的执行结果（绝不可能到了必须使用抛出异常的方式才能说明方法执行结果的地步，译者注），如果你确实需要通过抛出异常来表示方法的执行结果，那只能说明你这个方法做了太多事情，必须进行拆分。（这里原文的意思是，除非确实有异常发生，否则一个方法不应该仅仅是为了说明执行结果而抛出异常，也就是说，不能无病呻呤，译者注）

• 可以使用“抛出异常”的方式去着重说明不能被忽略的错误

我可以举个现实中的例子。我为我的Grivo（我的一个产品）开发了一个用来登录的API（Login），如果用户登录失败，或者用户并没有调用Login方法，那么他们调用其他方法时都会失败。我在设计Login方法的时候这样做的：如果用户登录失败，它会抛出一个异常，而并不是简单的返回false。正因为这样，调用者（用户）才不会忽略（他还没登录）这个事实。

• 不要清空了堆栈跟踪（stack trace）信息

堆栈跟踪信息是异常发生时最重要的信息，我们经常需要在catch块中处理一些异常，有时候还需要重新上抛异常（re-throw）。下面来看看两种方法（一种错误的一种正确的）：

错误的做法：

try
{
    // Some code that throws an exception
}
catch (Exception ex)
{
    // some code that handles the exception
    throw ex;
}

为什么错了？因为当我们检查堆栈跟踪信息时，异常错误源变成了“thorw ex;”，这隐藏了真正异常抛出的位置。试一下下面这种做法：

try
{
    // Some code that throws an exception
}
catch (Exception ex)
{
    // some code that handles the exception
    throw;
}

有什么变化没？我们使用“throw;”代替了“throw ex;”，后者会清空原来的堆栈跟踪信息。如果我们在抛出异常时没有指定具体的异常（简单的throw），那么它会默认地将原来捕获的异常继续上抛。这样的话，上层代码捕获的异常还是最开始我们通过catch捕获的同一个异常。

拓展阅读：

C# 异常处理（Catch Throw）IL分析

• 异常类应标记为Serializable

很多时候，我们的异常需要能被序列化。当我们派生一个新的异常类型时，请不要忘了给它加上Serializable属性。谁会知道我们的异常类会不会用在Remoting Call或者Web Services中呢？

• 使用”抛出异常”代替Debug.Assert

当我们发布程序后，不要忘了Debug.Assert将会被忽略。我们在代码中做一些检查或者验证工作时，最好使用抛出异常的方式代替输出Debug信息。

　　将输出Debug信息这种方式用到单元测试或者那些只需要测试当软件真正发布后确保不会出错的场合。

• 每个异常类至少包含三个构造方法

做这件事相当简单（直接从其他的类型粘贴拷贝相同的代码即可），如果你不这样做，那么别人在使用你编写的异常类型时，很难遵守上面给出的一些规则的。

　　我指的哪些构造方法呢？这三个构造方法可以参见这里。

 

不要重复造轮子

已经有很多在异常处理方面做得比较好的框架或库，微软提供的有两个：

Exception Management Application Block

Microsoft Enterprise Instrumentation Framework

Beachten Sie, dass diese Bibliotheken möglicherweise keinen großen Nutzen für Sie haben, wenn Sie einige der oben genannten Regeln nicht befolgen.

VB.NET

Wenn Sie das gelesen haben Ganz Nachdem Sie diesen Artikel gelesen haben, werden Sie feststellen, dass der gesamte Beispielcode in C# geschrieben ist. Das liegt daran, dass C# meine bevorzugte .NET-Sprache ist und VB.NET einige eigene Sonderregeln hat.

• Simulation der using-Anweisung in C#

Leider ja , gibt es in VB.NET keine using-Anweisung. Jedes Mal, wenn Sie die nicht verwalteten Ressourcen eines Objekts freigeben, müssen Sie Folgendes tun:

Wenn Sie nicht folgen Wenn Sie die DISpose-Methode auf die oben beschriebene Weise aufrufen, treten wahrscheinlich Fehler auf (Informationen zum Aufrufen der Dispose-Methode finden Sie im neuen Buch. Anmerkung des Übersetzers ).

• Verwenden Sie keine unstrukturierte Ausnahmebehandlung (On Error Goto)

Unstrukturierte Ausnahmebehandlung wird auch „On Error Goto“ genannt, dass „Goto-Anweisungen eher schädlich als hilfreich sind“. Bitte entfernen Sie alle goto-Anweisungen aus Ihrem Code. Ich garantiere Ihnen, sie haben keinen Nutzen. (Edsger Dykstra schlug die „Goto-Schadenstheorie“, Semaphoren und PV-Primitive vor und löste damit das interessante Problem der Essphilosophen. Als er im Buch „Software Story“ über die Fortran-Sprache sprach, war er bei ihm. Anmerkung des Übersetzers)

>Ich hoffe, dass dieser Artikel einigen Menschen helfen kann, ihre Codierungsqualität zu verbessern. Ich hoffe auch, dass dieser Artikel der Beginn einer Diskussion darüber ist, wie man Ausnahmen effektiv behandelt und macht Programme, die wir schreiben, sind robuster.

Worte des Übersetzers:

Ich habe einen Mangel, ich weiß nicht, ob Es gibt Internetnutzer, die genauso sind wie ich. Ich bin ein Langsambrenner, und das Gleiche gilt für die Technologie. Ich habe erst dann etwas gespürt, als viele Dinge ihren Höhepunkt erreichten. Der Hauptgrund ist, dass ich neue Dinge nicht besonders mag; der zweite Grund ist, dass ich immer das Gefühl habe, dass ich Dinge verändere, bevor ich sie beherrsche, was bedeutet, auf halbem Weg aufzugeben. Tatsächlich weiß ich auch, dass das sehr schlecht ist. Schließlich ist die IT-Branche eine sich schnell entwickelnde Branche, und sie wird ins Hintertreffen geraten, sobald sie nicht mithalten kann.

Gerade wenn ich auf eine so widersprüchliche Situation stoße, konzentriere ich mich beim Erlernen von Wissen darauf, die Kommunikation zwischen ihnen zu lernen Die Natur, die sogenannte Universalität, wird sich in zehn, zwanzig oder sogar dreißig Jahren wahrscheinlich nicht ändern oder verschlechtern. Wenn das Unternehmen, in dem Sie derzeit arbeiten, im tatsächlichen Entwicklungsprozess verwendet hat, Wenn Sie darauf bestehen, dass Sie sich nicht darauf konzentrieren, „wie Sie mit diesem Framework ein gutes System erstellen“, geraten Sie möglicherweise in ein paar Jahren ins Hintertreffen. Und wenn man die Gemeinsamkeiten in der Programmierung studiert, wie Protokolle, Interaktionsprinzipien zwischen Systemen usw., werden diese in jedem Netzwerkkommunikationssystem verwendet, egal ob es sich um ein scheinbar veraltetes PC-Programm, ein Webprogramm oder eine derzeit beliebte mobile APP handelt verwendet werden, und die Grundprinzipien sind dieselben. Je mehr ich es beobachte, desto mehr wird mir klar, dass neue Dinge herauskommen, die die Suppe zu verändern scheinen, ohne die Medizin zu verändern (leichte Übertreibung:-))

Deshalb gebe ich es an diejenigen, die wie ich sind und nicht wirklich folgen. Der Rat für Menschen, die neu in neuen Dingen sind oder sich schon lange mit einer bestimmten Art fester Entwicklungsarbeit beschäftigen, ist, die Gemeinsamkeiten zwischen ihnen herauszufinden Technologien und bleiben Sie nicht an der Oberfläche der Technologie, es sei denn, Sie interessieren sich ausreichend für Neues und haben genügend Energie.

Die oben genannten Worte wurden auch während des Diskussionstreffens unseres Unternehmens geteilt.

Autor: Zhou Jianzhi

Quelle: http://www.php.cn/

Das Urheberrecht dieses Artikels liegt beim Autor und Blog Park. Ein Nachdruck ist jedoch ohne Zustimmung des Autors gestattet und ein Link zum Originaltext muss an einer gut sichtbaren Stelle auf der Artikelseite angebracht werden. Im Übrigen bleibt die Geltendmachung der gesetzlichen Haftung vorbehalten.

Ergänzung:

Über die „Zwei-Runden-Traversal“-Ausnahmebehandlungsstrategie von CLR.
Wenn eine Anwendung über eine mehrschichtige verschachtelte Struktur zum Abfangen von Ausnahmen verfügt und eine Ausnahme auf der untersten Schicht auftritt (eigentlich gilt das Gleiche auch für die mittlere Schicht), gibt die CLR der Suche nach dem Catch-Anweisungsblock auf der obersten Ebene Priorität Sehen Sie sich die Ebene an, in der die Ausnahme ausgelöst wird. Wenn nicht, springen Sie einfach zur vorherigen Ebene, um zu suchen. Suchen Sie weiter nach der „vorherigen Ebene“ der vorherigen Ebene. Von dieser bis zur obersten Ebene der Anwendung.
Dies ist die „erste Runde“ des Durchlaufens der CLR-Anwendung verschachtelter Ausnahmeabfangstrukturen – das Finden des geeigneten Ausnahmehandlers.
Wenn auf einer bestimmten Ebene ein Ausnahmebehandler gefunden wird, beachten Sie, dass die CLR ihn nicht sofort ausführt, sondern zum „Unfallort“ zurückkehrt und die „zweite Runde“ erneut durchläuft, um das Letzte auszuführen „Zwischenebenen“-Anweisungsblock, führen Sie dann
aus, um den Ausnahmehandler zu finden, und gehen Sie schließlich von dieser Ebene nach oben, wobei Sie alle endgültigen Anweisungsblöcke ausführen.

Das Obige ist der Inhalt der Best Practices (Übersetzung) für die Ausnahmebehandlung in . NET. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!