Ich bin versucht, ein Suffix wie "Ex" hinzuzufügen, um Methoden (mit ähnlichen Signaturen) zu unterscheiden, die Exceptions von denen, die das nicht tun, werfen.
Gibt es eine solche Konvention?
Ausnahmen sind Teil der Methodensignatur in Java, daher wäre eine solche Namenskonvention überflüssig.
Tu das nicht.
Das ist wie die Frage "Gibt es eine Benennungskonvention für Methoden, die zwei Strings als Parameter verwenden".
Java hat Ausnahmen überprüft, was bedeutet, dass Sie diese trotzdem deklarieren müssen. So können Sie leicht sehen, ob eine Ausnahme ausgelöst wird und welche Art von Ausnahme. Sie können nicht einmal Code kompilieren, der die Methode aufruft, ohne Ausnahmecode hinzuzufügen.
Aktualisierung: Es scheint, dass Sie über Methoden verfügen, die prüfen, ob eine bestimmte Bedingung zutrifft, aber Sie möchten nicht nur false zurückgeben, sondern eine Ausnahme auslösen, wenn die Bedingung nicht erfüllt wird. damit Sie auch eine Erklärungsnachricht übermitteln können (in der Exception). Ich denke, ein Präfix von "assert" oder "secure" macht Sinn:
%Vor%Ja, Sie benennen sie genauso wie Methoden, die das nicht tun.
Ist die Ausnahmespezifikation nicht ausreichend?
Bearbeiten: Wenn Sie ähnliche Methoden haben, die werfen / nicht werfen, empfehle ich das Muster %code% / %code% ( %code% wird durch die Operation ersetzt). .NET Framework verwendet es häufig ( %code% , %code% , %code% usw.).
Bearbeiten: Coding Horror: TryParse und die Ausnahme-Steuer
Ungarische Notation für Methoden, die Ausnahmen auslösen? Quel Horror!
Meinst du, dass die Option aktiviert oder deaktiviert ist? Warum in aller Welt würdest du das tun wollen?
Wenn Sie darüber nachdenken, müssen Sie Ihre Konvention zu jeder Methode hinzufügen, da immer das Potenzial eines Fehlers oder einer NPE oder einer anderen Sache besteht, die schief gehen könnte.
Die "throws" -Klausel reicht aus, wenn Sie Ausnahmen überprüft haben, und es gibt keinen guten Zweck auf Gottes grüner Erde für ungeprüfte Ausnahmen.
Tu es nicht. Bitte.
Wenn Sie diese Methoden differenziert brauchen, können Sie das sicher in der Benennung tun, ohne ein Suffix oder irgendetwas zu verwenden, was (wie andere schon angedeutet haben) ziemlich gruselig ist.
>Warum haben:
%Vor%und (sagen wir)
%Vor%wenn Sie es tatsächlich zu einem bedeutungsvollen Teil des Namens machen könnten, indem Sie die eigentliche Absicht übermitteln:
%Vor%... oder eine beliebige Anzahl anderer (wahrscheinlich besserer) Namen, die tatsächlich die Absicht vermitteln, anstatt sich auf ein verwirrendes Suffix zu verlassen.
Es gibt nichts, was mir bekannt ist.
Meiner Meinung nach ist das einzige Mal, wenn etwas Sinn macht, in Unit-Testfällen (z. B. testFooExpectingException ()). Aber darüber redest du nicht.
Es gibt keine solche Konvention, da jede Methode Ausnahmen auslösen kann, unabhängig davon, ob Sie sie deklarieren oder nicht. Es ist auch etwas überflüssig in der heutigen Zeit von IDE-Tooltips (außer Sie verwenden natürlich keine IDE).
Ich bin neugierig zu erfahren, warum Sie versucht sind, eine solche Namenskonvention zu verwenden.
Es gibt keine Konvention und das Hinzufügen eines Exs macht den Namen schwieriger zu lesen und hässlich, wenn man nach dem durchschnittlichen Java-Programmierer sucht.
Aber manchmal könnte ich mir vorstellen, dass es Ihren Code schneller verständlich macht, wenn Sie Methoden ausprobieren, die wahrscheinlich eine Ausnahme auslösen. Vor allem, wenn sie nicht markiert sind.
Es muss nicht so hässlich sein, wie es in vielen c / c ++ - Programmen der Fall ist, in denen Sie _name oder mName für Mitglieder oder iValue für Ganzzahlen verwenden. Aber in Java gibt es auch einige Konventionen. Wenn eine Methode eine Ganzzahl zurückgibt, wird ihr vorangestellt: is ... set, get und test sind die am häufigsten verwendeten Beispiele dafür. All diese Dinge sind im Methodenkopf, durch Rückgabetypanmerkungen usw. dokumentiert. Aber das Hinzufügen eines Wortes zum Funktionsnamen macht es einfacher und schneller zu lesen und zu verstehen.
Warum nicht versuchen, Programmierern, die Ihren Code lesen, einen unbewussten Hinweis zu geben, dass diese Methode wahrscheinlich eine Ausnahme auslöst. Wie tryCopyFile anstelle von tryWriteFile.
Hin und wieder kommt es zu einem Fall, in dem es sinnvoll ist, einen Methodennamen wie %code% zu haben (gibt einen Standardwert zurück, wenn der tatsächliche Wert ungültig ist, für Code, der dies nicht tut sich zu sehr um reale Werte im Vergleich zu Platzhaltern kümmern) oder umgekehrt %code% (für einen Fail-Fast-Code, bei dem ein fehlender Wert technisch möglich ist, aber einen Fehler im Code anzeigt, der den Wert festlegen soll).
Aber der Punkt hier ist nicht "Methode 2 löst eine Ausnahme aus, Methode 1 nicht" - weil, wie oben erwähnt, jeder Code könnte werfen ein %code% . Der Punkt ist, dass die beiden Methoden unterschiedliche Fehlerbehandlungssemantiken haben, die für verschiedene Anwendungsfälle spezifisch sind, und das ist was die Methodennamen zu erfassen versuchen.
Selbst dann wäre der Code normalerweise sauberer, wenn Sie mit dem einen oder anderen Verhalten davonkommen und die Methode %code% aufrufen könnten.
Eine nützliche Parallele dazu könnte die Unterscheidung zwischen Ungarisch und Ungarisch in ungarischer Notation sein. (Siehe auch dieses Stück über Kodierungskonventionen von Joel on Software.)
Aufruf der Methode %code% ist Systems ungarisch.
Warum würdest du so etwas in Java machen? Es hat bereits in der Sprache eingebaute Ausnahme-Spezifizierer. Der Compiler verhindert, dass Sie eine Methode aufrufen, die explizit eine Exception auslöst, ohne dass Ihrerseits etwas unternommen wird, um die Exception weiterzugeben oder zuzulassen?