Laden...

Meinungen zu Methodik vom Kapseln von try-catch

Erstellt von LaTino vor 8 Jahren Letzter Beitrag vor 8 Jahren 3.052 Views
LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 8 Jahren
Meinungen zu Methodik vom Kapseln von try-catch

Hi,

bin mal wieder an einem Review und stolpere hier vermehrt über eine Technik, die mir Unbehagen bereitet. Anstelle eines Methodenaufrufs in dieser Form:


try 
{
    return instanceObject.DoSomething();
}
catch(Exception ex)
{
    //logging, behandlung...
   return new ResultObject { Success = false }; //nur als Beispiel für ein Ergebnisobjekt
}

...wird folgendes gemacht:


class ExceptionSourceClass
{
    public Result DoSomethingSecurely(Func<Result> delegatedMethod)
    {
        try { return delegatedMethod(); }
        catch(Exception ex) { return HandleException(ex); }
    }
}

//Anwendung:
var wrappedHandler = new ExceptionSourceClass(); //nur zur Verdeutlichung, wird meistens als Property übergeben, woanders erzeugt
var result = wrappedHandler.DoSomethingSecurely(instanceObject.DoSomething);

Was haltet ihr von diesem Hokuspokus? Meine derzeitige Einschätzung ist:

  • Möglichkeit, zur Laufzeit das Ergebnis bei Ausnahmen zu verändern, in dem man eine andere ExceptionSourceClass benutzt
  • kein try-catch-"Overhead" im Client (weniger Code-Rauschen)
  • kein try-catch-"Overhead" im Client (dh die Ausnahmebehandlung wird verschleiert)
  • Übergabe von Delegaten als Parameter empfinde ich rein subjektiv als unsaubere OOP im vgl. zur Übergabe von Objekten
  • deutlich mehr Zeitaufwand zum Verstehen des Codes (-> Dokumentation etc. pp)

Insgesamt macht das Konstrukt auf mich ein bisschen den Eindruck, dass ein Softwareentwickler über das Ziel hinausgeschossen und over-engineered hat.

Was denkt ihr?

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

16.834 Beiträge seit 2008
vor 8 Jahren

kein try-catch-"Overhead" im Client (dh die Ausnahmebehandlung wird verschleiert)

ist für mich schon ein absolutes KO Kriterium, dass man über die positiven Seiten nicht mehr nachdenken muss 😉

Für mich sieht das nach einer schmutzigen Zweckentfremdung aus.

W
872 Beiträge seit 2005
vor 8 Jahren

Es erinnert mich etwas an das Railway Oriented Programming in F#. In F# passt das sehr gut, da das Pattern Matching vollständige Abdeckung aller Fälle erzwingt.

2.207 Beiträge seit 2011
vor 8 Jahren

Hallo LaTino,

ich habe auch immer Probleme damit, wenn irgendwo eine Exception fliegt und ich "von aussen" etwas anderes, "verschleiertes" zurück bekomme. Das ist immer ein verfälschtes Ergebnis.

Gruss

Coffeebean

LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 8 Jahren

Ist nur das Sahnehäubchen. Dieser spezielle Part (der, soweit die Checkins das korrekt sagen, komplett von ein und demselben Entwickler ist) wimmelt nur so von Delegat-Parametern, und das halte ich so schon für grenzwertig.
Aber an dieser speziellen Stelle finde ich das aber nicht nur unübersichtlich, sondern eben auch schädlich. War mir aber unsicher, ob diese Sicht meinem eigenen, völlig anderem Stil geschuldet ist, oder ob andere das auch so sehen.

Reine Stilfragen werden beim Review weniger kritisch bewertet - das ist der ganze Hintergrund.

@weismat: muss wohl wieder ein bisschen F# machen. Der Code auf der verlinkten Seite hat einen gewissen Coolness-Faktor, das lässt sich nicht abstreiten 😉

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)