[linux-l] RS-232 oder USB lesen mit (Schauder...) Java Os-unabhaengig

Oliver Bandel oliver at first.in-berlin.de
Mo Okt 3 04:45:23 CEST 2005


Moin,


On Sun, Oct 02, 2005 at 09:57:01PM +0200, olafBuddenhagen at gmx.net wrote:
> Hallo,
> 
> > Die Value, die in den switch geht, ist nicht von dem Enum-Typ abgedeckt,
> > den man checken will.
> 
> OK, das ist tatsächlich ein Problem. Dachte der Compiler behandelt
> enum-typen etwas differenzierter... :-(


... tja, was man nicht so alles denkt. ;-)

...warum wol die meisten Fehler beim anwender auftauchen?

1) Der programmierer kreiert Bugs
2) Der programmierer testet - wenn übrhaupt - nur die Fehler, die er für möglich hält
3) Der Anwender /die Anwenderin gibt irgendwelches Zeugs ein
   ("ganz unmöglich! Was machen Sie denn da?!") und das Programm
   macht einen Abgang -> der erste erfolgreiche Softwaretest!
   => "ganz unmöglich! Was machen Sie denn da?!"'s Fortsetzung: "Wenn Sie sowas
       eingeben ist es ja kein Wunder, daß der Compuzter abstürzt"
   (Statt der richtigen Bezeichnung: "Wie schön, daß wenigstens Sie, liebe
    Aushilfskraft hier mal endlich einen ordentlichen Softwaretest durchführen!")



> 
> Übrigens kann man enum-typen glaub' ich teilweise schützen, indem man
> sie in ein struct packt... Was natürlich nicht gerade schön ist :-)

Naja, wenn das was hilft..  ;-)

Haste denn mal Beispielcode für dieses Bug-Verhüterli? ;-)


> 
> > > Bei enums sollte man keinen default benutzen.
> > 
> > Warum nicht?
> > default könnte vergessene Cases abfangen.
> 
> Nein, eben nicht. Wenn man *kein* default: hat, werden vergessen cases
> schon beim kompilieren abgefangen.

Naja, aber andere Fehler fragt der nicht ab.
Dann eben default erst mal auskommentieren, aber nachdem man fertig ist
wird der default wieder von den Kommentar-Klammerungen befreit.
Dann hat man eine zusätzliche Abfrage drin.

Man kann shcliesslich auch mehrere Case-Abfragen
hintereinander angeben, aber hat vergessen, die alle
gesondert zu behandeln.


(Eigentlich immer gut: jedes case bekommt sein eigenes break.)

Daß man da so viel herum rudern muß und sich "gute Styles" ausdenken muß,
sagt schon einiges über die Sprache aus, die man verwendet.

Ach bei OCmal gibt es Tips, um Fehler zu vermeiden, aber es sind wesenztlich
weniger notwendig.
In C  & Co. hat man da einfach mehr zu rudern.


> 
> Das mit den grundsätlich falschen enum-typen ist natürlich 'ne andere
> Geschichte.

Eine, die man aber nicht vernachlässigen kann.
Auch solche Fehler können auftreten.


> Das sollte man wahrscheinlich schon versuchen abzufangen,
> bevor man in die switch-Anweisung geht...
> 
> >                 default: fprintf( stderr, "hard programming error! BUG! file: %s line: %d\n", __FILE__, __LINE__);
> >                           exit(EXIT_FAILURE);
> 
> Für sowas gibt's ein standard-konstrukt, das nennt sich assert().


Komisch nur, daß dieses assert() aber diese Meldung nicht so ausgibt, auch
wenn es so ähnlich in der mapage steht.
assert() ist ein Makro. Wer weiß, was der macht?


Hast Du denn ein lauffähiges Codebeispiel, das mir auch solche
Ausgaben ausgibt?

Davon abgesehen ist explizites hinschreiben sicherlich auch nicht schlecht.
Bei den Makros in C ist es ja eh immer so ne Sache, das war's doch auch beim
Einlesen von Zeichen via stdlib?!


> 
> Vernünftige C-Programmierer benutzen das zuhauf... Damit kann man schon
> 'ne Menge Mist abfangen.

Naja, assert() benimmt sich hier irgendwie anders, als es sollte.
Oder bin ich schon zu platt heute?!


Ciao,
   Oliver



Mehr Informationen über die Mailingliste linux-l