ich hatte heute eine Idee, habe sie aber nicht ganz umgesetzt bekommen, ich hoffe ihr könnt mir da ein wenig weiterhelfen. Es geht um statische Methoden in Exception-Klassen die ich gerne weitervererben würde. Mal als Beispiel:

// MainException:
static void checkString_empty(string testString) throw(MainException) {
	if (testString.size() == 0) {
		throw MainExcetion(ERROR_EMPTY_STRING);
	}
}

diese könnte ich ja dann einfach per

MainException::checkString_empty(...);

überall einsetzen, was ich für eine recht angenehme Fehlerabfrage halte

Nun würde ich aber auch gerne Ableiten können. Eine abgeleitete Klasse XYZ_Exception sollte dann natürlich eine XYZ_Exception werfen.
Ist sowas irgendwie zu bewerkstelligen, oder muss ich sie dann für jede abgeleitete Klasse einen override machen?

Vielen Dank schonmal!
Narase

in jede Klasse die ich schreibe die gleiche Methode zu implementieren die mir einen String prüft

Warum packst du sie in eine Klasse?

Die Idee dahinter ist halt dass ich einfach die Exceptionklasse auch direkt die Bedingung prüfen lasse, praktisch eine Abwandlung von assert(). Finde es angenehmer als in jede Klasse die ich schreibe die gleiche Methode zu implementieren die mir einen String prüft

wenn du gewisse vor- (oder nachbedingungen, in diesem sinne: https://de.wikipedia.org/wiki/Design_by_contract ) prüfen willst, ist es momentan wohl am besten, das makro "Ensures" aus der guideline support library zu verwenden. der vorteil davon ist, dass es in zukunft sehr leicht möglich sein wird, dass dann direkt in C++ (in form von attributen) ausdrücken zu können.

du willst nämlich sicher nicht, dass am ende ein user mit irgendeiner seltsamen fehlermeldung wie "string länge ist null" konfrontiert wird, oder? überlege dir gut das design!

#include "gsl_assert.h"
//...
void (string foo) {
  Expects(foo.size() > 0);
  //...
}

//später
void (string foo) 
  [[expects: foo.size() > 0]]
{
 //...
}

(hier: https://github.com/Microsoft/GSL/ )

auf deine art und weise muss du überall, wo du deine invarianten überprüfen willst, die exception-klasse einbinden. die exception-klasse brauchst du aber eigentlich nur, wenn du sie wirfst - oder an der stelle, wo du den fehler behandelst.

übrigens:
explizite exception-spezifikationen sind deprecated

throw(MainException) //geht bald (!) nicht mehr!

Narase schrieb:

in jede Klasse die ich schreibe die gleiche Methode zu implementieren die mir einen String prüft

Warum packst du sie in eine Klasse?

Wo soll ich sie sonst haben? Statisch in irgendeiner Source? Eine Klasse die die Funktion braucht muss sie auch implementieren.

@dovve
das hört sich soweit gut an, gilt es dann nur für Vorbedingungen?
Wenn ich zb sowas mache

string s;
s = readLineFromAFile().trim();

würde die neue Funktion so etwas abfangen können oder steh ich damit dann eher schlecht dar?

Statisch in irgendeiner Source?

Nein

Narase schrieb:

Eine Klasse die die Funktion braucht muss sie auch implementieren.

Nein.

Wo soll ich sie sonst haben? Statisch in irgendeiner Source? Eine Klasse die die Funktion braucht muss sie auch implementieren.

Wie wäre es als freie Funktion in einem Namespace? Wobei ich noch immer nicht so wirklich den Sinn sehe.

Narase schrieb:

das hört sich soweit gut an, gilt es dann nur für Vorbedingungen?

Expects für Pre- und Ensures für Post-Conditions. Siehe: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-pre

Narase schrieb:

Wenn ich zb sowas mache

string s;
s = readLineFromAFile().trim();

würde die neue Funktion so etwas abfangen können oder steh ich damit dann eher schlecht dar?

std::string hat kein trim() - kommst du von Java? Das würde auch erklären, warum du ne statische Funktion in der Klasse willst und wo das throw(MainException) herkommt.

Aber allgemein: WAS soll da abgefangen werden (was ist "so etwas")?
a) Fehler beim Lesen -> könnte ne Exception sein
b) String ist nach dem trim leer -> sowas sollte keine Exception sein, das ist ja ein ganz normaler Fall und keine Ausnahme, oder nicht?

Mein Grundgedanke ist konkret dieser: Ich lese daten aus einer XML aus. Nun sollen die Daten in der XML nicht leer sein, ich könnte also hingehen und jedes mal

if (string.size() < 1){
    throw Exception("Blah");
}

dazwischen packen. Das würde aber meinen Code zumüllen. Ich könnte auch jedes mal sowas implementieren

string Classname::checkString(string test, string msg){
    if (test.size() < 1){
        throw Exception(msg);
    }
    return test;
}

Diese Methode könnte ich einfach um den read herumpacken, damit wäre ich den Klotz schonmal weg.
Aber wenn ich sie nun in verschiedenen Klasse brauche könnte ich sie...
1. ... in jeder Klasse definieren. Abgelehnt wegen Redundanz
2. ... als public in einer Klasse definieren und eine Instanz von ihr erstellen. Auch abgelehnt
3. ... in eine Source packen und sie einfach so statisch machen. Fände ich auch unschön, außerdem kommt Eclipse mit sowas nicht sonderlich gut zurecht

Ich habe 2 Klassen, beide haben ihre eigene Execption-Klasse.
class Person; PersonException
class Animal; AnimalException
Beide Klasse lesen im Konstruktor ihre Attribute aus einer XML (warum, lassen wir mal dahingestellt).
Wenn beide Exceptions von MainException erben und es so funktionieren würde wie ich mir das vorstelle, könnte ich einfach beide male die jeweilige Exception-Klasse nutzen um die Prüfungen der XML-Daten zu machen. Da es nicht funktioniert bin ich auf andere Methoden angewiesen, von denen jede so ihre Nachteile hat, ganz oben dabei die Redundanz

Dein Konzept mit Zuordnung Klasse <-> Exceptionklasse ist sehr merkwürdig. Aber wenn du es unbedingt so willst:

5. ... eine Templatefunktion mit der Exeptionklasse als Templateparameter. Ohne static! Mit using kann man die Schreibweise sogar abkürzen.

Wie genau würde das mit der Kürzung per using funktionieren? Hab mir gerade die cpp-Referenz dazu durchgelesen, so ganz komme ich nicht dahinter.

Hm, war leider ein Irrtum, das geht nur mit Typen, nicht mit Funktionen.

Aber wie gesagt, dein Konzept ist merkwürdig. Der Typ der Exception sollte Informationen über den Fehler beinhalten und nicht über die Klasse, aus der sie geworfen wurde.