Modernes Exception-Handling Teil 2 - Hinter den Kulissen

SideWinder

Weil du dann nicht weißt woher und warum die Exception geflogen ist, könnte quasi ja von überall herkommen. Ist aber oft als "last resort" ganz außen in Programmen üblich.

MfG SideWinder

_ro_ro

@SideWinder sagte in Modernes Exception-Handling Teil 2 - Hinter den Kulissen:

Weil du dann nicht weißt woher und warum die Exception geflogen ist, könnte quasi ja von überall herkommen. Ist aber oft als "last resort" ganz außen in Programmen üblich.

MfG SideWinder

Im Artikel steht aber auch daß man Exceptions zentral auffangen soll. Das beißt sich schon ein bischen, meinen Sie nicht auch?

Denn: Eine zentrale Fehlerbehandlung funktioniert ja nur wenn die Exceptions entsprechend klassifiziert sind. Und genau damit weiß man auch wo sie gefallen sind. Noch dazu wenn ein Backtrace verfügbar ist.

MFG

SideWinder

Beides ist imho richtig: fange kontextlose Exceptions möglichst lokal und kontextbehaftete dann zentral. Ich versuch's mal mit einem Beispiel:

try
{
    auto x = query_database_a(); // wirft network_exception wenn datenbank nicht erreichbar

    // wenn hier drin noch viele andere query_database_b(), etc. wären, die auch network_exception werfen, wüsste man unten im catch nicht welche datenbank überhaupt die war die nicht erreichbar war => daher möglichst kleiner try/catch-block
}
catch(network_exception& ne)
{
    // network_exception ist kontextlos, aber weil ich try nur um ein statement rumgemacht habe, weiß ich sofort, dass es sich um ein problem bei query_database_a() handeln muss:
    throw database_a_error("Could not reach database A."); // diese exception hier kann man nun möglichst zentral catchen und einen error dialog anzeigen oder ähnliches
}

Hoffe das Beispile hilft. Ist zumindest ein Weg den ich in C#/Java immer gehe, kenne mich mit aktuellem C++ Exception Best Practices nicht aus.

MfG SideWinder

_ro_ro

@SideWinder

ich hatte mal ein Programm (Perl) das lief nicht auf jedem System. Selbst der Kollege der den Code entwickelt hatte wusste nicht warum, außer der Feststellung daß es wohl ein lokales Problem sein müsse.
Kurzerhand setzte ich den ganzen Code in einen try-Block und fand damit raus woran es gelegen hat. Natürlich war es ein lokales Problem aber das war ja vorher schon klar wenns bei allen anderen Kunden läuft nur bei dem einem nicht.

MFG

_ro_ro

@SideWinder

zu Deinem Code: Wenn eine network_exception von der Stange nicht unterscheidet zwischen einer nicht zustandegekommenen Verbindung und einer verlorenen Verbindung ist das ein Grund über eine eigene Klassifizierung nachzudenken, also eigene Exception-Klassen. darüber hinaus gibt es sicher auch in C# und Java Möglichkeiten vor einer Query den Verbindungsstatus abzufragen (ping).
Auf diese Art und Weise muss man nicht jedes Statement in einen eigenen try-Block setzen sondern einfach nur eine gezielte Ex werfen die zentral gefangen wird.

MFG

SideWinder

Auch wenn eine sehr gute Exception geworfen wird, wird sie evtl. nicht zwischen database_a und database_b unterscheiden wenn es zwei Connections sind die zurselben Art von DB gehen, aber sind natürlich alles konstruierte Beispiele, wenn die Exception gut genug ist, spricht natürlich absolut nichts dagegen den catch-Block so weit außen wie möglich zu machen.

MfG SideWinder

_ro_ro

@SideWinder

so ist es. Es kommt ja auch darauf an, was mit der Exception gemacht werden soll. Ich hatte z.B. mal ein Programm für einen Datentransfer von Oracle nach MySQL zu entwickeln, da kam es nur darauf an, daß dieses Programm bei nicht Erreichbarkeit einer der beiden (egal welche) in einer Warteschleife weiterläuft bis die Verbindung wieder steht.

Schönen Sonntag!

SideWinder

Die Aussage ist wohl nur, wenn du innerhalb einer Methode einen try/catch-Block machst, dann ist es best practice ihn so klein wie möglich zu machen. Dass du weit außen ein einziges try/catch rund um app.Run() hast, ist davon nicht betroffen.

MfG SideWinder

omggg

Ich fahre da zwei Philosophien (je nach Projekt)... Entweder, alles "nach oben" weitergeben - oder aber die try-catch-Blöcke so früh und klein wie möglich wählen, damit man a weiß, was die Exception verursachte, und b ggf. darauf entsprechend regieren kann, ohne das Programm zu beenden.

Ein von @_ro_ro vorgeschlagener Mischmasch führt meines Erachtens nur zu Chaos.

_ro_ro

@omggg sagte in Modernes Exception-Handling Teil 2 - Hinter den Kulissen:

Ich fahre da zwei Philosophien (je nach Projekt)... Entweder, alles "nach oben" weitergeben - oder aber die try-catch-Blöcke so früh und klein wie möglich wählen, damit mit man a weiß, was die Exception verursachte, und b ggf. darauf entsprechend regieren kann, ohne das Programm zu beenden.

Ein von @_ro_ro vorgeschlagener Mischmasch für meines Erachtens nur zu Chaos.

Ich habe gar nichts vorgeschlagen. Ich finde nur, daß der Artikel in sich widersprüchliche Aussagen trifft.

Im übrigen ist meine Frage immer noch nicht beantwortet. MFG

omggg

@_ro_ro sagte in Modernes Exception-Handling Teil 2 - Hinter den Kulissen:

@omggg sagte in Modernes Exception-Handling Teil 2 - Hinter den Kulissen:

Ich fahre da zwei Philosophien (je nach Projekt)... Entweder, alles "nach oben" weitergeben - oder aber die try-catch-Blöcke so früh und klein wie möglich wählen, damit mit man a weiß, was die Exception verursachte, und b ggf. darauf entsprechend regieren kann, ohne das Programm zu beenden.

Ein von @_ro_ro vorgeschlagener Mischmasch für meines Erachtens nur zu Chaos.

Ich habe gar nichts vorgeschlagen. Ich finde nur, daß der Artikel in sich widersprüchliche Aussagen trifft.

Im übrigen ist meine Frage immer noch nicht beantwortet. MFG

Kein Grund, aggressiv zu werden oder zu eskalieren ... Ich habe nur den Subtext gedeutet.

Th69

@_ro_ro sagte in Modernes Exception-Handling Teil 2 - Hinter den Kulissen:

Frage zum Artikel, da steht, daß man nicht den ganzen Code in einen try-Block setzen soll. Warum nicht?

@_ro_ro sagte in Modernes Exception-Handling Teil 2 - Hinter den Kulissen:

Ich habe gar nichts vorgeschlagen. Ich finde nur, daß der Artikel in sich widersprüchliche Aussagen trifft.

Welche Sätze meinst du denn genau? Zumindestens in diesem (Teil-)Artikel finde ich keine Aussagen bzgl. der Vermeidung eines globalen try...catch-Handlers.

Schlangenmensch

Da der Thread bzw der Artikel ursprünglich mal "Modernes Exception Handling" hieß; in modernem C++ gibt es auch andere Möglichkeiten der Fehlerbehandlung, z.B. mit std::optionaloder noch neuer std::except. Hier ein Artikel dazu: https://devblogs.microsoft.com/cppblog/cpp23s-optional-and-expected/

_ro_ro

@Schlangenmensch

die Erfahrung daß man mit Exceptions seine Fehlerbehandlung vereinfachen kann teile ich auf jeden Fall. Darüber habe ich auch schon vor ein paar Jahren Artikel geschrieben.

MFG