Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C++CLI / VB .Net / .Net-Framework » SerialPort - warum Exceptions?

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
07.08.2006, 17:11 Uhr
ao

(Operator)


Hallo zusammen,

ich lese mich gerade in die Klasse System.IO.Ports.SerialPort aus dem .NET-Framework ein (MSDN, http://msdn2.microsoft.com/en-us/library/system.io.ports.serialport_methods.aspx ). Da steht sinngemäß folgendes:

Die Write-Methoden (mehrere Überladungen) geben am Ende die Anzahl der geschriebenen Bytes zurück. Außerdem schmeißen sie eine TimeoutException, wenn während des Schreibvorgangs die eingestellte Timeoutzeit abgelaufen ist.

Für die Read-Methoden gilt Entsprechendes: Rückgabe der Anzahl der gelesenen Bytes plus Exception bei Zeitüberschreitung.

Ich frage mich: Was soll das? Wozu überhaupt eine (teure!) Exception, wenn schon am Rückgabewert Erfolg oder Misserfolg zu erkennen ist? Und wie erkenne ich im Timeout-Fall, wieviele Bytes zuvor noch erfolgreich übertragen werden konnten; einen gültigen Rückgabewert habe ich ja dann nicht?

Kann mir das einer erklären?

Danke

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
07.08.2006, 21:32 Uhr
Bruder Leif
dances with systems
(Operator)


Moin!

Ich tippe mal auf Konsistenz -- wenn was schiefgeht, werfen wir eine Exception, und zwar immer. Auch, wenn der Programmierer mit ein bisschen Hirnschmalz selbst drauf kommt, dass etwas nicht geklappt hat. Bei anderen Methoden gibt es vielleicht keinen Rückgabewert, der Erfolg oder Misserfolg anzeigen kann, und man braucht die Exception, also lieber immer eine werfen, wenn was schiefläuft.

Was die Anzahl erfolgreicht verarbeiteter Bytes angeht: Immer nur ein Byte auf einmal schreiben, dann gibts nur 0 (Exception) oder 1 (Erfolg) Sorry, aber was besseres fällt mir momentan auch nicht ein...
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
07.08.2006, 22:51 Uhr
ao

(Operator)


Na ja, was ich bisher vom .NET-Framework gesehen hab, war ziemlich gut durchdacht. Darum wunderts mich sehr, auf ein API zu treffen, das so kaputt aussieht wie MFC und ATL zusammen.

Bei ner Schnittstelle mit Flusssteuerung auf unterster Ebene (RTS/CTS) ist eine Zeitüberschreitung geradezu ein normaler Betriebszustand, darum kommts mir arg übertrieben vor, auf sowas mit einer Exception, also mit einem panischen Hilfeschrei, zu reagieren.

Ich hoffe ja immer noch, dass ich das einfach nur missverstanden habe ...

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C++CLI / VB .Net / .Net-Framework ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: