Frage zu Strings einer Exception

[DagobertDuck]

Guten Abend,

da ich immer wieder Projekte sehe, in denen Nachrichten der Exceptions als Konstanten behandelt werden und manchmal auch nicht, stelle ich die frage jetzt mal hier.

In meinem aktuellen Projekt verwende ich z. B.

throw new LogicException("no valid next state can be reached"); (kommt mehrmals vor)
throw new LogicException("there is no active game at the moment");
throw new LogicException("no more cards left");
throw new LogicException("wrong dice"); (kommt zweimal vor)
...

Sind das also Magic Strings bzw. sollten diese zu Konstanten refactored werden?
throw new LogicException(InOuput.NO_VALID_STATE_REACHABLE);
throw new LogicException(InOutput.NO_ACTIVE_GAME);
...

oder ist dies nicht notwendig (auch wenn die Meldungen mehrmals vorkommen)?

Eine andere Frage:
In einer Klasse meines Projektes habe ich derzeit das Attribut private final boolean requiresFireplace;, das darüber entscheidet, ob ein Item eine Feuerstelle benötigt, um gebaut zu werden. Der Name passt noch ganz gut, allerdings benötigt ich auch den Getter, der dann nach Java Namenskonvention so aussieht:

    public boolean isRequiresFireplace() {
        return requiresFireplace;
    }

Hier ist der Name dann wieder sehr unpassend. Hat jemand eine andere Namens-Idee?

Viele Grüße

 

[mihe7]

Wie wäre es mit isFireplaceRequired ?

Sind das also Magic Strings bzw. sollten diese zu Konstanten refactored werden?

Das dient normalerweise der Internationalisierung bzw. in Deinem Fall woher eher der Vereinheitlichung der Fehlermeldungen für das Testsystem.

 

[DagobertDuck]

Das dient normalerweise der Internationalisierung bzw. in Deinem Fall woher eher der Vereinheitlichung der Fehlermeldungen für das Testsystem.

Dann ist das also sinnvoll? Damit hätte ich dann bestimmt 10-15 Konstanten in meiner InOuput Klasse. Aber das ist in Ordnung, oder macht hier eine enum-Klasse mehr Sinn?

 

[kneitzel]

Was ist das für ein InOutput Klasse? Also
a) so Konstanten gehören normalerweise zu der Klasse, in denen die Exception geworfen wird. Das klingt in meinen Ohren massiv nach eine falschen Gliederung - da wurde nicht sauber in Objekte aufgeteilt sondern wie beim Scripting einfach fachliche Dinge in unterschiedliche Scripts gesteckt. Und Ein- und Ausgabe ist da scheinbar in InOutput gelandet ... Und alle möglichen und unmöglichen Stellen referenzieren da nun drauf und nutzen das ganz wild wie sie wollen ... keine Kapselung, keine objektorientierung u.s.w.

b) sind das zumindest aus meiner Sicht KEINE Benutzerausgaben oder so. (Exceptions mit Ihren Informationen sind Internas. Die gehen nicht an den Benutzer. Der Benutzer muss ggf. an diese heran kommen (Logfile o.ä.) aber nur um diese dann an den Support / Entwickler weiter zu geben. Denn in den Exceptions geht es um technische Dinge. Die logischen Dinge sind in der Oberfläche. Die Oberfläche fängt Exceptions und gibt dann eine - ggf. Internationalisierte - Fehlermeldung aus.

So ist zumindest, wie wir es handhaben.

Und nein: Da machen Enums keinen Sinn. Andererseits: Es gibt nichts, das Du nicht auch mit Enums machen kannst - das hast Du ja schon schön bewiesen

 

[mrBrown]

Ich würde in dem Fall außerdem statt einer generischen Exception auch spezifische für die einzelnen Fälle nutzen, die dann durchaus von einer gemeinsamen erben können.