Objekt erzeugen.. (fehlerfall im Konstruktor) ?

BorisDieKlinge

Habe eine klasse aus der ich instanzen erzeuge, nun wird im Kontruktor aus den übergabeparameter ermittel das diese falsch sind... nun soll theoritsch kein Objekt erzeugt werden, was so nicht geht..

Was gibts für lösungen umd diese Problem zu umgehen?

class A{

A(int i){

  if( i=0)
    //Abrruch? 
  }

}

Vertexwahn

Exceptions

GPC

Oder prüf vor Instantiierung, ob der Parameter valide ist. Meinetwegen per static-Member-Methode von A oder mit 'ner normalen Funktion:

class A {
public:
  static bool isValid(int i) {
    if (deineBedinungWahrIst)
      return true;
    return false;
  }

  //Rest deiner Klasse

};

//irgendwo in main:
if (A::isValid(7));
  A myA(7);

MfG

GPC

BorisDieKlinge

sowas habe ich mir schon gedacht:)

In Punkte Exceptions hab ich mir etwas eingelesen.. so weit ich weis kann man sog. Exceptions klassen machen, welceh best. fälle beabeiten..! Nun frag ich mich ob man für jede klasse die exception benutzt auch eine extra Exceptionskasse erzeugen muss...

Edit: @GPC: ja sieht ziemlich gerissen aus;) aber ich Glaube excpetions sind etwa Edler oder;)

Vertexwahn

BorisDieKlinge schrieb:

sowas habe ich mir schon gedacht:)

In Punkte Exceptions hab ich mir etwas eingelesen.. so weit ich weis kann man sog. Exceptions klassen machen, welceh best. fälle beabeiten..! Nun frag ich mich ob man für jede klasse die exception benutzt auch eine extra Exceptionskasse erzeugen muss...

nö nich jede Klasse die eine Exception benutzen will braucht eine eigen - du kannst z. b. für alle deine Klassen die Exception std::exception verwenden

Simon2

Hi Boris,

erstmal: Werfen kann man alles (was keinen privaten CopyCtor hat).
Wenn einen der wilde Affe beißst, kann man sogar seine Returnwertrückgabe statt über return über throw machen (mit Referenzen klappts aber "leider" nicht) ... nettes Feature dabei: Es macht der damit weiter, der den Typ fängt und das ist nicht unbedingt der direkte Aufrufer der Funktion.

Ich würde zwar dringend davon abraten, aber es zeigt, dass es quasi keine (durch die Sprache vorgegebene) Anforderung an das gibt, was man wirft.

Sinnvoll aber ist es, entweder die stdexcep-Teile (aus dem gleichnahmigen Header) zu verwenden (man darf auch einfach einen std::runtime_error("Mein Fehlertext") werfen) , oder von ihnen abzuleiten - aber unbedingt notwendig nicht.

BorisDieKlinge schrieb:

...
Edit: @GPC: ja sieht ziemlich gerissen aus;) aber ich Glaube excpetions sind etwa Edler oder;)

Vor allem: Es verschiebt einen Teil der Verantwortung nach Außen, ohne wirklich das Problem zu lösen ! Was, wenn im Konstruktor nun festgestellt wird, dass "isValid()" nicht zutrifft ? Abbrechen ? ...

Gruß,

Simon2.

GPC

Simon2 schrieb:

BorisDieKlinge schrieb:

...
Edit: @GPC: ja sieht ziemlich gerissen aus;) aber ich Glaube excpetions sind etwa Edler oder;)

Vor allem: Es verschiebt einen Teil der Verantwortung nach Außen, ohne wirklich das Problem zu lösen ! Was, wenn im Konstruktor nun festgestellt wird, dass "isValid()" nicht zutrifft ? Abbrechen ? ...

Äh, wenn isValid true für Parameter zurückliefert, die eigentlich false liefern müssten, wurde bei der Implementation von isValid geschlampt. Nicht mehr und nicht weniger.

Simon2

GPC schrieb:

...
Äh, wenn isValid true für Parameter zurückliefert, die eigentlich false liefern müssten, wurde bei der Implementation von isValid geschlampt. Nicht mehr und nicht weniger.

Das meinte ich nicht, sondern den Fall:

class A {
  int* p;
public:
  static bool isValid(int i) {
    return deineBedinungWahrIst;
  }
  A(int i) {
     if(isValid(i)) { // sollte dieselbe Prüfung gemacht werden und keine andere
        p = new int[i];
     }
     else .... // äh, ja was hier ?
  }
  //Rest deiner Klasse
};

Damit steht der A-Progrmmierer vor derselben Frage wie vorher: Was, wenn ich Daten erhalten, mit denen ich kein gültiges Objekt erzeugen kann ?

Und der A-Nutzer ist gezwungen, jedesmal selbst die Prüfung (mit evtl. Fehlerhandling) zu machen, was Aufwand und Risiko bedeutet:

//irgendwo in main:
int i = 7;
if (A::isValid(i) && saeckeweise && andere && Conditions && gehtFunktionGeht(i)) {
  Viel();
  was();
  noch();
  getan(i); // getan ändert leider i
  werden();
  muss();
  ...
  // 10.000 Zeilen später
  ...
  A myA(i); // Hupps hier hat i gar nbicht mehr den oben getesteten Wert !
  ....

Ich habe also nichts gegen eine isValid()-Funktion, aber ich bin skeptisch, dass sie in diesem Zusammenhang wirklich eine hilfreiche Alternative ist.

Gruß,

Simon2.

GPC

Ach so. Das ist was anderes.