www.mikrocontroller.net

Forum: PC-Programmierung C: Funktionen und Rückgabewerte


Autor: Ralf Altmann (warpnine)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich bin gerade dabei mir ein Schema zu überlegen, wie ich Rückgabewerte
von Funktionen handhaben soll. Gemeint sind Rückgabewerte, die Aussage
über evtl. aufgetretene Fehler geben.

Ich habe mir folgende Möglichkeiten überlegt:

1. Rückgabewerte sind fest in den Funktionen hinterlegt, also z.B. 0
für keinen Fehler, 1 für Fehler Nr.1, usw.
Das prüfen dieser Fehler kann jetzt auf zwei Arten geschehen:
Entweder man prüft auch direkt auf die entsprechenden Rückgabewerte,
oder indirekt, indem man zum besseren Verständnis den festen
Rückgabewerten per #define aussagekräftige Namen verpasst, und damit
dann den Rückgabewert prüft.

2. Die aus Punkt 1 beschriebenen per #define angelegten Fehler-Namen
werden auch in den Funktionen verwendet.
Das wiederum macht die Funktionen besser lesbar.
Allerdings stellt sich dann die Frage, wie es gehandhabt werden soll,
wenn z.B. zwei Funktionen einen gleichen Fehlernamen verwenden, obwohl
die Funktionen nichts miteinander zu tun haben.
Ein zentrales H-File mit allen Fehlern halte ich für unklug, zumal in
Betracht gezogen werden soll, dass auch Bibliotheken programmiert
werden sollen. Das heisst, bei einer Änderung einer bereits bestehenden
Zuweisung müssen alle Bibliotheken neu übersetzt werden.
Es sei denn, man kann sicherstellen, dass Bestehendes nie geändert
wird.

3. ??????
Wie macht ihr das denn?

Ralf

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Punkt 2 ist eine verbreitete Vorgehensweise.
Die Zuordnung von Fehlernummern und deren Bedeutung wird als
unveränderlich angesehen. Wenn eine (neue) Funktion einen bislang
unbekannten Fehlercode liefern soll, muss die Fehlernummernliste
entsprechend erweitert werden, es darf aber keine "alte" Fehlernummer
inhaltlich geändert werden.

So machen es Betriebssystem-APIs; gewisse Fehlercodes sind sogar
betriebssystemübergreifend standardisiert.

Sieh Dir mal errno.h oder error.h Deines Compilers an.

Natürlich lassen sich nicht alle möglichen Fehler auf dieses feste
Fehlernummernmodell abbilden - in diesem Falle werden oft eigene
Fehlercodetabellen für Libraries verwendet.

Die Verwendung eines enums für Fehlercodes erscheint mir übrigens recht
vorteilhaft, da a) moderne Debugger dann den symbolischen Namen anzeigen
können (was mit #defines nicht geht) und b) man sich nicht um die
tatsächlichen numerischen Werte Gedanken machen muss, solange man neue
Elemente immer "hinten" anhängt.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt noch eine 3. Methode:

Eine Extrafunktion zum Abfragen, welcher Fehler in der letzten Funktion
aufgetreten ist.

Das hat den Vorteil, dass du in der zu prüfenden Funktion nur einen
Rückgabewert für den Fehlerfall verbrätst ("Es ist irgendein Fehler
aufgetreten") und die restlichen Rückgabewerte Nutzdaten sind.

Welcher Fehler genau aufgetreten ist, kann mit der Extrafunktion
geprüft werden.

Autor: Nico S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stichwort: errno

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die dritte hier emfpohlene Methode bringt eigentlich keinen Vorteil. Was
soll es bringen, wenn der Returncode ohnehin für Fehlerinformation
verwendet wird, dann nur zwischen Fehler und kein Fehler zu
unterscheiden? Ausserdem erfordert er das Ablegen der Fehlerinformation
ausserhalb der Funktion - global? - Bäh! So was gibts leider in C und
auch Standardbibliotheken machen das, aber das muss man deswegen nicht
nachmachen ;)

"..., kann mit der Extrafunktion..." Genau, "kann", wird aber
nicht... Fehlermeldungen, die ignoriert werden können, sind keine
wirksamen Fehlermeldungen.

Zum zentralen Fehler-Headerfile. Hat seine Berechtigung und die
Wiederverwendung allgemeiner Fehler ist auch nicht schlecht. Bastelst
du unterschiedliche Bibliotheken mit eigenen Headers und jeweils
eigenen (aber gleichlautenden) Fehler-Defines, kommt es zu Problemen.
Da helfen enums oder namespaces (müsste es nach C99 mittlerweile auch
in C geben).

Ich würde eine "globale" Headerdatei für Fehler anfangen. Vermeide
auf jeden Fall die Verwendung von "magischen Zahlen" und arbeite
unbedingt mit symbolischen Namen, also enums oder halt defines!

Gruß

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"errno" als Beispiel für modulare Fehlercodes hinzustellen, ist schon
fast kriminell.

Besser: Fehlercodes nicht sequentiell numerieren, sondern Bereiche
definieren. Global wird nur der Bereich des jeweiligen Moduls
definiert, also beispielsweise:

<errors-global.h>
   #define ERR_MODULE_1   0x0100
   #define ERR_MODULE_2   0x0300
   #define ERR_MODULE_3   0x0200

<module-1.h>
   #define ERR_MOD1_WASSOLLICHDAMITANFANGEN (ERR_MODULE_1+0x01)
   usw.

C++ Namespaces sind auch ganz nett, lösen das Problem aber auch nicht
ganz, weil halt immer noch irgendwer global numerieren muss. Einzig
Strings vgl. Java-Classnames sind eindeutig, aber etwas unhandlich.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer hat die 3. Methode empfohlen? Ich nicht.

Ich habe geschrieben, dass es diese Methode gibt und welchen Vorteil
ich darin sehe.

Wieso kann man nicht sachlich beim Thema bleiben und muss Leute als
kriminelle Ignoranten titulieren?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, sorry, war etwas zu agressiv formuliert. Erwähnt hat es übrigens
Rufus.

Weil ich weder Unix/Linux noch Windows als Vorbild für Modularisierung
und API-Design anraten möchte. Die errnos von Unix sind eine
Katastrophe, ähnlich schlimm wie Microsofts Namensgebung von APIs. Ich
hatte letzthin mal mit einem Backup-Programm zu tun, das einen
Schreibfehler per FTP lauthals auf ein verschmutztes Medium schob.
Typischer Fall von etwas zu schmalspurig konzipierter Fehlerhandhabung.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.