Eine mögliche Exception ist erst einmal ein Seiteneffekt einer Methode, diese ist dann nicht mehr referentiell transparent (a.k.a. "pur"). Z.B. darf es keine Rolle spielen, welche von zwei referentiell transparenten Methoden zuerst ausgeführt wird, aber wenn Methoden Exceptions werfen, ist das natürlich nicht mehr gegeben, denn die erste Exception "gewinnt". Da referentiell transparente Methoden viele Vorteile bieten, die man im funktionalen Umfeld zu schätzen weiß (lazy evaluation, memoization u.s.w.), sollte man sich gut überlegen, ob man mit Exception arbeiten will, zumal der Mechanismus zum Catchen von Exceptionein ein nicht-lokaler Kontrollfluss (oder böse gesagt, eine leicht limitierte Form von "goto") ist, der schwer zu kontrollieren ist.

Try, Either, Option oder Validation sind dagegen ganz normale Werte, und nutzen das Typsystem, um den Rückgabewert exakt zu beschreiben (eben die Tatsache, dass es u.U. nicht möglich ist, selbigen zu bestimmen). Ich finde es irgendwie seltsam, dass sich das anstelle von Exceptions so schwer durchsetzt. Wenn eine Methode "mehrwertige" Rückgabewerte hat, schreit doch auch niemand nach einem speziellen Mechanismus, sondern man greift ganz automatisch zu Listen, Sets u.s.w.

Natürlich gibt es Stellen, wo Exceptions ihre Berechtigung haben, hauptsächlich dann, wenn die Ausnahme wirklich so schwerwiegend ist, dass man nicht angemessen reagieren kann, bei Legacy-Code (und Bibliotheken, die als solcher angesehen werden können) oder wenn dann ein Programmierfehler vorliegen muss. Wenn man aber eine komplizierte Hierarchie von verschachtelten Fehlern konstruieren will, läuft definitiv etwas falsch.

Einen besseren Hoster kann ich nicht vorschlagen, aber wenn hier Syntaxhighlighting nicht vorhanden ist, obwohl es seit Jahren von Nutzern gewünscht wird, ist das hier wohl generell nicht der richtige...