Return in try-catch-Block

[dedlfix]

Hi!

In welcher Reihenfolge schreibt man als Best Practice eigentlich die verschiedenen Statements? Also, ich meine folgendes: Schreibt man besser

if ($test == 1) {
} elseif ($test == 2) {
}

>   
> oder  
>   
> ~~~php
  

> if (1 == $test) {  
> } elseif (2 == $test) {  
> }

? Ich weiß, das ist eine unwichtige Frage, weil's ja das gleiche ist, es interessiert mich aber. Ich habe mal gelesen (weiß leider nicht mehr wo und finde grade auf die Schnelle auch nichts), dass das zweite Beispiel zu bevorzugen sei, da es übersichtlicher ist. Man könne schneller die relevante Information erkennen (wobei mein obiges Beispiel nicht sehr gut ist, für so ein Konstrukt könnte ich auch switch verwenden). Intuitiv würde ich die erste Variante bevorzugen.

Wie du so schön sagt, beides kommt aufs Gleiche raus - wenn man sich nicht vertippt und statt == nur ein = nimmt. Dann ergibt die zweite Variante einen Syntaxfehler, weil einem konstanten Ausdruck nichts zugewiesen werden kann. Das wäre insofern ein Vorteil. Andererseits sollte das eigentlich spätestens beim Testen des Programms auffallen, dass wa was unerwartetes passiert. Dann kann man den Fehler beseitigen und der eine kleine Vorteil ist nicht mehr relevant.

Ich persönlich finde die zweite Variante nicht übersichtlicher, weil sie umgekehrt zur außerhalb des Programmierens üblichen Anordnung ist. "Wenn 2 gleich dem Inhalt von $test ist" empfinde ich sprachlich unschöner als "Wenn der Inhalt von $test gleich 2 ist".

Da muss ich mir nochmal was mehr Mühe bei jeder einzelnen Methode geben, wenn es um solch eine Fehlerbehandlung geht. Bisher hab ich in den meisten Fällen eine Exception geworfen, die dann immer weiter nach oben gereicht wurde (meist bis zum FC). In den seltensten Fällen hat eine aufrufende Methode evtl. auftretende Fehler abgefangen und verarbeitet (einzige Ausnahme, die mir gerade einfällt, war ein Aufruf meiner Klasse File; hier wurden Fehler direkt aufgefangen, beispielsweise wenn eine Datei nicht vorhanden war, da man damit rechnen konnte).

Um Fehlerbehandlung oder auch Alternativen sinnvoll zu implementieren sollte man nicht nur aus der Sicht des Programmierers schauen, sondern vor allem auch aus der Sicht der Anwender (diese Gestalten vor dem UI) und der Verwender (andere Codeteile, die die entsprechende Routine aufrufen).

Lo!