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

class A{

A(int i){

  if( i=0)
    //Abrruch? 
  }

}

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

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;)

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

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.

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.

...
Ä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.