Wann Exception bzw. direkte Fehlerbehandlung?

Nexus

Der Begriff "Manager" sagt an sich nicht viel aus. Manchmal werden Klassen so genannt, wenn den Leuten kein konkreter Name einfällt. Ab und zu sieht man den Begriff auch im Zusammenhang mit exzessiver Anwendung von Design Patterns, wo keine nötig sind. Ruvi meinte wohl was Anderes, daher auch seine Anführungszeichen.

Du hast also nichts verpasst

Ruvi

Aus dem Kopf getippt und stark gekuerzt.

Im Grunde verwaltet der User_Mgr alle Nutzer und ist fuer die Erstellung, Initialisierung zustaendig.
Gibt bei Bedarf einzelne Nutzer oder die gesamte Nutzerliste an jeden der sie will.

class User {};

class User_Mgr {

private:
vector <unique_ptr <User>> usr_list;       //Nutzer container 

bool write_user_in_db();                   //in file oder db schreiben

public:
bool create_usr();                   // Nutzer anlegen Daten werden validiert
bool delete_usr(uint usr_id);
bool initialize_usr_list();      //Beim Programmstart Nutzer aus File/DB lesen

};

CppNeuland

Ah ok danke, also ein Verwaltungsobjekt.

@Nexus: Na, da habe ich ja noch mal Glueck gehabt Bei Projekten mit viel Design-Pattern blicke ich so gut wie nie durch. Die einzelnen Pattern, ueber die ich so gelesen habe, hoeren sich alle ganz toll an, aber einen Code mit Abstract Factory, Factory, Wrapper und wo man dann auch noch die Algorithmen austauschen kann(mir faellt der Name nicht ein), klingt zwar alles toll, aber da durch zu steigen, was das Programm nun konkret macht, wenn die Doku schlecht ist, ist schon eine Herausforderung.

Jedenfalls fuer mich.

knivil

Wenn du im Konstruktor keine Exception wirfst, lässt du Objekte am Leben, obwohl sie nur halbwegs konstruiert sind. Sie befinden sich also in einem Zustand, in dem sie nicht richtig verwendbar sind. Klasseninvarianten können nicht mehr garantiert werden, als Folge muss man das Objekt als Benutzer auf Gültigkeit prüfen oder nachträglich initialisieren.

1.) Das haengt vom jeweiligen Objekt bzw. Anwendungsfall ab.
2.) Im Hinblick auf C++11 und move-only Typen ist ein Null-Objekt sehr sinnvoll. Deine pauschale Aussage lehne ich deswegen ab.

Zeiger jeweils unmittelbar auf nullptr zu setzen

Ja, das tue ich, um beispielsweise mittels assert ihre Gueltigkeit zu pruefen. Die Gueltigkeit kann nicht immer vorrausgesetzt werden, da nach aussen beispielsweise open / close / read angeboten wird und intern ein Zeiger/Handle verwaltet wird. Der User kann also read ohne open bzw. nach einem close aufrufen. Wie darauf zu reagieren ist, ist anwendungsabhaengig. Ich habe mich auch schon mal dafuer entschieden, dass ein read ohne open oder auch wiederholtes open zur No-Op wurde.