Errorhandler vs try-catch

Computer: Software & Programmierung .NET & C#
#1

Hallo,
ich möchte in einer Methode u.a. eine Sounddatei abspielen. Den Soundplayer mit Pfad zur wav-Datei habe ich instanziert mit

new System.Media.SoundPlayer(@„C:\Windows\Media\chord.wav“);

Das Funktioniert!
Wenn die wav-Datei nicht gefunden wird, hängt das Programm fest.
Ich meine mich zu erinnern, dass es in VB6 am Ende der Prozedur einen Errorhandler gab, der die Fehlermeldungen abfängt. Das war einfach.Die C#-Literatur empfiehlt mir die (etwas umständliche) Codierung mit try-catch

try
{
  //Sounddatei im Pfad abspielen
}

catch(Exception)
{
   //Fehlerbehandlung
}

Geht’s nicht etwas einfacher?

vG
der_kps

#2

Hallo,

„try catch“ ist die richtige strukturierte Methode, statt einem „On Error GoTo“. Das ist unter VB.NET nun auch so, nicht nur unter C#.
Abgesehen davon könntest Du natürlich vorher prüfen, ob die abzuspielende Datei überhaupt existiert: Namespace „IO.File“.
Aber sicherheitshalber würde ich hier trotzdem auch noch ein try catch einbauen, da nicht unbedingt sichergestellt ist, dass hinter der .wav-Datei wirklich auch eine Audio-Datei steckt.

Gruß
Thomas

#3

Danke für den Hinweis, so mog wi dat!

Apropos „goto“: Ich benutze in C# nach If auch ein goto auf eine Sprungmarke, weil ich das von Assembler und VB6 so kenne. Es funktioniert unter C#, ist aber in der Literatur nirgends erwähnt. Ist das „unschön, schnell und schmutzig“ oder gibt es stilechte Alternativen?

Vg
der_kps

#4

Hi,

sicherlich ist GOTO in der Referenz und Büchern erwähnt.

http://openbook.galileocomputing.de/visual_csharp_20…

Es ist aber i.d.R. nicht notwendig es zu benutzen, da es der Code unübersichtlicher macht, wenn man es so benutzt wie in VB oder ASM.

In C# benutzt man es in Switch statements (eher selten gesehen) oder häufiger: um mehrfach verschachtelte Schleifen gezielt und als Ganzes zu verlassen. Wenn man das Ganze mit BREAK oder CONTINIUE versucht, wird es eher noch unübersichtlicher.

Gruss
Joey

#5

Tja, dann muss ich mir das mit goto abgewöhnen.
Ich habe das jetzt mit do-while gemacht.
Sieht auch besser aus. Geht doch!

vG
der_kps

#6

Hi,

für die Verwendung von Resourcen wie Dateien, Datenbanken, Netzwerkverbindungen… wurde das „using“ Konstrukt eingeführt, um try-catch-finally in diesen Fällen knapper und übersichtlicher zu handhaben. In diesem Fall würde das vor allem die Resource Datei betreffen.

Verschiedene Varianten mit Vor- und Nachteilen für eine leicht andere Situation, in der der Sound eine eingebetteten Resource ist.

http://stackoverflow.com/q/1161229/3088138

Die Abfrage der Existenz der Datei per Erzeugen eines FileStream in einem „using“-Block kann man mit dem zweiten Konstruktor des Soundplayers kombinieren, der ein Stream-Argument akzeptiert:

import System.IO.FileStream;
import System.IO.FileMode;

...
using(Stream sound= new FileStream(@"C:\Windows\Media\chord.wav"), FileMode.Open) ){
 // Datei existiert und ist lesbar
 var player = new System.Media.SoundPlayer(sound);
 //Play synchron, da sonst die Datei sound während der Benutzung geschlossen wird (?)
 player.PlaySync();
 //Datei wird automatisch geschlossen
} catch( FileIOException e) {
 Ausgabe "Datei existiert nicht"
}

Gruß, Lutz