Dieses Verhalten / diese Möglichkeiten sind nur in der Debug-Version aktiv, in der Release-Version passiert nichts.
Debug.Assert(AUSDRUCK) testet den AUSDRUCK und gibt ein Meldungsfenster aus, wenn AUSDRUCK = False ist.
Das Programm kann unterbrochen werden und es stoppt genau in der Debug.Assert-Zeile.
Zunächst muss der NameSpace Diagnostics hinzugefügt werden.
Wo ist ein solcher Test sinnvoll?
Zunächst überall da, wo wir sicher sind, dass wir nichts falsch gemacht haben.
Wir überzeugen uns davon, dass wir nichts falsch gemacht haben:
Hier kann eigentlich nichts schiefgehen. Oder?
So sieht das schon wesentlich freundlicher aus.
Wir können nun sicher sein, dass dann, wenn wir etwas falsch gemacht oder vergessen haben, eine Meldung angezeigt wird. So können wir sofort eingreifen und den Fehler korrigieren.
Solche Tests können wir überall im Programm einfügen, wo vielleicht doch die Möglichkeit besteht, dass eventuell und unter Umständen Unvorhergesehenes passieren kann.
Ich wiederhole noch einmal:
Diese Tests finden nur in der Debug-Version unseres Programms statt, in der Release passiert nichts.
Absolut hilfreich sind diese Tests in Programmen, wo damit zu rechnen ist, dass im Zuge der Weiterentwicklung neue Features hinzukommen.
Wenn also die vorhandenen Features alle sorgfältig durch-enumeriert sind, können wir überall, wo anhand der Feature-Kennung eine Aufruf-Verteilung vorkommt, einen Test einbauen, der die Liste der Features überwacht:
In diesem Fall ist das Hinzufügen eines neuen Features eine reine Fleißarbeit. Wir sorgen dafür, dass ein Aufruf mit der Kennung des neuen Features erfolgt und müssen nur noch überall, wo Debug.Assert() zuschlägt, vor das
einfügen.
Wir können dann sicher sein, dass wir praktisch alle Stellen im Programm erwischt haben, bei denen wir Hand anlegen müssen.
Das Ausfüllen der Funktionalität ist natürlich ein anderes Problem.
Debug.Assert(AUSDRUCK) testet den AUSDRUCK und gibt ein Meldungsfenster aus, wenn AUSDRUCK = False ist.
Das Programm kann unterbrochen werden und es stoppt genau in der Debug.Assert-Zeile.
Zunächst muss der NameSpace Diagnostics hinzugefügt werden.
Wo ist ein solcher Test sinnvoll?
Zunächst überall da, wo wir sicher sind, dass wir nichts falsch gemacht haben.
Wir überzeugen uns davon, dass wir nichts falsch gemacht haben:
Hier kann eigentlich nichts schiefgehen. Oder?
So sieht das schon wesentlich freundlicher aus.
Wir können nun sicher sein, dass dann, wenn wir etwas falsch gemacht oder vergessen haben, eine Meldung angezeigt wird. So können wir sofort eingreifen und den Fehler korrigieren.
Solche Tests können wir überall im Programm einfügen, wo vielleicht doch die Möglichkeit besteht, dass eventuell und unter Umständen Unvorhergesehenes passieren kann.
Ich wiederhole noch einmal:
Diese Tests finden nur in der Debug-Version unseres Programms statt, in der Release passiert nichts.
Absolut hilfreich sind diese Tests in Programmen, wo damit zu rechnen ist, dass im Zuge der Weiterentwicklung neue Features hinzukommen.
Wenn also die vorhandenen Features alle sorgfältig durch-enumeriert sind, können wir überall, wo anhand der Feature-Kennung eine Aufruf-Verteilung vorkommt, einen Test einbauen, der die Liste der Features überwacht:
VB.NET-Quellcode
- Enum FeatureList
- Feature1
- Feature2
- Feature3
- Feature4
- End Enum
- Private Sub TueEtwas(ByVal feature As FeatureList)
- ' ...
- Select Case feature
- Case FeatureList.Feature1 : BeargeiteFeature1()
- Case FeatureList.Feature2 : BeargeiteFeature2()
- Case FeatureList.Feature3 : BeargeiteFeature3()
- Case FeatureList.Feature4 : BeargeiteFeature4()
- Case Else
- Debug.Assert(False) ' neuer Case
- Return
- End Select
- ' ...
- End Sub
In diesem Fall ist das Hinzufügen eines neuen Features eine reine Fleißarbeit. Wir sorgen dafür, dass ein Aufruf mit der Kennung des neuen Features erfolgt und müssen nur noch überall, wo Debug.Assert() zuschlägt, vor das
einfügen.
Wir können dann sicher sein, dass wir praktisch alle Stellen im Programm erwischt haben, bei denen wir Hand anlegen müssen.
Das Ausfüllen der Funktionalität ist natürlich ein anderes Problem.
Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch
Ein guter .NET-Snippetkonverter (der ist verfügbar).
Programmierfragen über PN / Konversation werden ignoriert!
Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch
Ein guter .NET-Snippetkonverter (der ist verfügbar).
Programmierfragen über PN / Konversation werden ignoriert!