Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

21

12.11.2008, 17:38

Zitat von »"knivil"«

Ueber Bibliotheksgrenzen hinweg sollten auch keine Exceptions geworfen werden.
Meinst du damit, dass andere Bibliotheken generell keine Exceptions werfen dürften (wenn man Exceptions, die in anderen Bibliotheken geworfen werden, in seinem eigenen Code behandelt, wird ja die Grenze der Bibliothek bereits überschritten)? Falls ja, dann bin ich anderer Meinung.

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

22

12.11.2008, 17:50

Genau das meinte ich mit den zwei Lagern am Anfang. Vorallem man kann noch soviele Argumente bringen. Am Ende macht es jeder wie er will und wir haben die typische Diskussion :roll: .
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

23

12.11.2008, 17:53

Zitat von »"Nox"«

Genau das meinte ich mit den zwei Lagern am Anfang. Vorallem man kann noch soviele Argumente bringen. Am Ende macht es jeder wie er will und wir haben die typische Diskussion :roll: .

Das ist aber bei vielen Dingen so. Leute, die es sowieso auf ihre Art machen und sich nicht überzeugen lassen, gibt es immer. Ist das ein Grund, nicht darüber zu diskutieren? Man kann sich so gegenseitig ergänzen und lernt immer wieder Dinge, die man vorher noch nicht gewusst hat.

Und auch das mit den zwei Lagern stimmt nicht ganz: Ich denke, die Mehrheit der fortgeschrittenen C++-Programmierer setzt Exceptions ein (wenn auch nicht übermässig). Leute, die in C++ Exceptions stur zurückweisen, gibt es hingegen wenige. Leute, die Exceptions als Rückgabewerte benutzen, wahrscheinlich noch weniger.

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

24

12.11.2008, 19:12

Hmm ich weiß nicht wielange du im Forum bist, aber in meiner Karriere gabe es mindestens schon 3 solcher Diskussionen, die am Ende kein wirklich einstimmigen Ergebnisse hervorbrachten. Ich lasse mich aber gerne eines besseren belehren ;)
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

25

12.11.2008, 20:08

Zitat von »"Nox"«

Hmm ich weiß nicht wielange du im Forum bist

Zitat

Nexus
Anmeldedatum: 18.05.2008

Also noch nicht so lange. :)

Nun gut, ich habe diese Diskussionen nicht mitgekriegt und dachte, es wäre schon einen Versuch wert. Es muss ja nicht zwangsläufig in einem Flamewar enden. Bis jetzt fand ich die Konversation hier auch ertragbar... Meinst du, das hat keinen Sinn?

Aber wenn dich das Thema so stört, musst du ja nicht mitschreiben. ;)

Databyte

Alter Hase

Beiträge: 1 040

Wohnort: Na zu Hause

Beruf: Student (KIT)

  • Private Nachricht senden

26

12.11.2008, 20:51

Ich denke ich werde das in Zukunft so machen, dass ich exeptions in eine funktion
einbaue, wenn ich unbedingt einen return-Wert und eine Fehlerabfrage haben will.

Für den Rest mach ich mir Result-Klassen ( die find ich nämlich schlich gesagt TOLL xD)

27

12.11.2008, 20:52

Zitat von »"Databyte"«

Ich denke ich werde das in Zukunft so machen, dass ich exeptions in eine funktion
einbaue, wenn ich unbedingt einen return-Wert und eine Fehlerabfrage haben will.
Naja, so pauschal würde ich das nicht sagen. Du kannst ja auch void-Funktionen mit Exceptions behandeln. ;)

Zitat von »"Databyte"«

Für den Rest mach ich mir Result-Klassen ( die find ich nämlich schlich gesagt TOLL xD)
Was sind denn Result-Klassen?

Databyte

Alter Hase

Beiträge: 1 040

Wohnort: Na zu Hause

Beruf: Student (KIT)

  • Private Nachricht senden

28

12.11.2008, 21:14

Hab ich jetzt einfach mal so genannt...

Das sind einfach Klassen die nur ne Zahl ( bei mir jedenfalls ) enthalten,
aber trotzdem auf bool geprüft werden können

Hier nen "kleines" Beispiel ( heißt noch notify is aber falsch und wird dämnachst immer Result heißen ;)):

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
#pragma once



class TNotify;
template<class T_ErrorAbleClass_>
class TNotifyAble;


/*
 *  + TNotify
 *  -------------------------------------------------------------------------------------------------------------
 *  TNotify besteht aus einem INT, der einen Errorcode enthält.
 *  Diese Klasse enthält einen operatore für BOOL und kann so bei if (etc) benutzt werden
 *  behandelt werden
 *  -------------------------------------------------------------------------------------------------------------
 *
 *
 *
 *  + TNotifyAble< Erbende Klasse >
 *  -------------------------------------------------------------------------------------------------------------
 *  Macht eine Klasse Notifyable.
 *  Kann eine Notify Klassenweit(static) speichern.
 *  Enthält Funktionen zum setzen und Abrufen von fehlern.
 *  -------------------------------------------------------------------------------------------------------------
 *
 *
 *
 *  + TNotifyAble< Erbende Klasse >
 *    + TStdNotifyCatcher
 *  -------------------------------------------------------------------------------------------------------------
 *  Klasse zum speichern von Fehlern für normale Funktionen.
 *  Hat keine eigenen Variablen oder Funktionen... erbt nur von TNotifyAble
 *  -------------------------------------------------------------------------------------------------------------
 *
 *
 *
 */








///////////////////////////////////////////////// TNotify /////////////////////////////////////////////////



class TNotify
{
private:
    int     _m_NotifyCode_;
public:

    /*
        Konstruktor ( Keine Parameter )
    */
    TNotify()
        : _m_NotifyCode_( 0 )
    {}


    /*
        Konstruktor ( NotifyCode )
    */
    TNotify(int _notifyCode)
        : _m_NotifyCode_( _notifyCode)
    {}


    /*
        Gebt eine Referenz auf den Notifycode zurück
    */
    inline
        int
            GetNotifyCode()
                const
    {
        return (_m_NotifyCode_);
    }


    /*
        Setzt einen Notifycode
    */
    inline
        int
            SetNotifyCode(int _notifyCode)
    {
        return (_m_NotifyCode_ = _notifyCode);
    }


    /*
        Gibt zurück ob ein Fehler vorliegt
        true    = Fehler
        false   = Kein Fehler
    */
    inline
        bool
            IsNotify()
                const
    {
        return  ((_m_NotifyCode_ == 0)? (false):(true));
    }


    /*
        Gibt zurück ob ein Fehler vorliegt
        true    = Kein Fehler
        false   = Fehler
    */
    inline
        bool
            IsValid()
                const
    {
        return  ((_m_NotifyCode_ == 0)? (true):(false));
    }


    /*
        überladener cast-operator
            -> IsValid()
    */
    inline
        operator
            bool()
                const
    {
        return (IsValid());
    }
};


///////////////////////////////////////////////// TNotifyAble /////////////////////////////////////////////////


template<class T_ErrorAbleClass_>
class TNotifyAble
{
private:
    static TNotify          _m_LastNotify_;
public:
    /*
        Setzt einen Klasseweiten Notifycode
    */
    static
        TNotify
            SetNotify( TNotify _notify)
    {
        if( _notify.IsNotify() )
            return (_m_LastNotify_ = _notify);
        return (_notify);
    }

    /*
        Gint das letzte Notify zurück
    */
    static
        inline
            TNotify
                GetLastNotify()
    {
        return (_m_LastNotify_);
    }


    /*
        Gibt zurück ob eine Notify vorliegt
        true    = Fehler
        false   = Kein Fehler
    */
    inline
        bool
            IsNotify()
                const
    {
        return (_m_LastNotify_.IsNotify());
    }

};

template<class T_ErrorAbleClass_>
TNotify
    TNotifyAble<T_ErrorAbleClass_>
                ::_m_LastNotify_ = 0;


///////////////////////////////////////////////// TStdNotifyCatcher /////////////////////////////////////////////////


            
            
struct TStdNotifyCatcher
    : public TNotifyAble<TStdNotifyCatcher>
{};

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

29

12.11.2008, 21:23

exceptions als ersatz für rückgabewerte zu verwenden ist imo genauso falsch wie rückgabewerte als ersatz für exceptions...
es handelt sich um zwei unterschiedliche mechanismen.

exceptions sind ein mechanismus um auf verhältnisse zu reagieren die lokal nicht behandelbar sind. warum sollte ein aufrufer der selber noch nicht darauf reagieren kann alle möglichen fehlerfälle einer funktion die er verwendet behandeln müssen, nur um sie entsprechend nach oben weiterzuleiten. damit zwingst du einen aufrufer schonmal selbst entsprechende rückgabewerte zu haben etc.
imo ziemlich unschön, exceptions lösen dieses problem auf elegante art und weise. die exception fliegt so lange nach oben bis sie gefangen wird, also an eine stelle kommt wo genug information vorhanden ist um zu entscheiden wie reagiert werden soll, und das ohne dass jeder aufrufer dazwischen sich um alle möglichen fehler kümmern musste...

exceptions vertragen sich mit konstruktoren übrigens wunderbar, sie sind der einzige weg die konstruktion eines objektes abzubrechen. mir isses lieber wenn ein objekt nicht erzeugt wird als wenn ich nacher ein zombie objekt hab.

Faule Socke

Community-Fossil

Beiträge: 1 915

Wohnort: Schreibtischstuhl

  • Private Nachricht senden

30

12.11.2008, 21:42

Nun ich finde man sollte dort Rückgabewerte verwenden, wo es moglich ist. Es macht doch keinen Sinn, ne void methode zu erstellen und sie im fehlerfall exceptions rumwerfen zu lassen. Natürlich gibt es auch da ausnahmen z.b. "gaaanz schlimmer fehler du hast an der exe datei rumgebastelt du sau!" oder memory errors etc^^

Man kann sich auch ganz einfach fragen? Tritt der fehler öfter auf? Wenn man mal keine rechte für ne Datei hat sollten deshalb nicht gleich exceptions fliegen, man sollte aber auf keinen Fall Standardrückgabewerte benutzen. Wenn ne verbindung fehlschlägt das selbe. Wenn aber z.b. winsock nicht initialisiert werden kann (aus welchem grund auch immer), dann könnte man eine schmeissen, denn das Programm kann in einem solchen Fall ja nur schlecht weiterarbeiten. Wenn es also ein Fehler ist den der Anwender selber beheben kann (z.b. fehlende datei auch erstellen) keine exception. Wenn die anwendung den fehler ohne hilfe vom anwender beheben kann, noch besser - auch keine exception. wenn aber der fehler nicht behoben werden kann, exception und anwender benachrichtigen.

Wenn man ne exception nicht abfängt landet sie früher oder später beim system, das macht in der regel kurzen prozess und beendet das programm. Davor werden allerdings noch ein paar zwischenstufen durlaufen:

Wurde kein exception handler gefunden, wird unexpected() aufgerufen. Mit set_unexpected kann man eine eigene Funktion zur behandlung eines solchen fehlers angeben. Wurde keine angegeben geht es weiter zu terminate(). mit set_terminate kann man auch hier wieder eingreifen, ansonsten gehts zu abort(). ich hoffe ich hab jetzt keinen mist erzählt,

Socke

Werbeanzeige