URI is not hierarchical

M

Mart

Gast
Nach langem hab ich es geschafft mein Package in git rein zu bekommen aber

jetzt ist das in git eine JAR datei also zip ohne hierachie dings...

in meinem anderen projekt wo das importiert wird erbe ich zb von der klasse mit der methode

Java:
public final String getResource(String resourceName)
    {
        try
        {
            return getClass().getResource(resourceName).toString();
        } catch (NullPointerException e)
        {
            throw new NullPointerException("The Resource::  " + resourceName + "\nwas not found in:: " + this.getClass()
                    + " :: with the Name :: \nThis can be caused by not having \"opens PACKAGENAME\" in the module info so it's not accessible\nNull Pointer Exception occured::\n"
                    + e.getMessage());
        }
    }
diese ist aber in der jar datei


wie kann ich es jetzt schaffen dass klassen in meinem aktuellen projekt die methode schafft von den klassen in der jar ? bzw was gleich wertiges bekomme
 
M

Mart

Gast
ja ok war irgend ein korruptes package + ich war wieder mal dämlich dass es gerade so rauscht... falsche klasse importiert das ist traurig
 

Oneixee5

Top Contributor
Also ich erinnere mich an deine Diskussionen, wie Code am "idiotensichersten" aussehen sollte. Bei allem Respekt aber der Code unter #1 ist da nahe dran.
 
K

kneitzel

Gast
getResource(String resourceName) ruft getResource(String resourceName) auf. Eine NPE wird behandelt - in dem eine NPE geworfen wird.

Also eine Exception fangen um dann eine Exception zu werfen, ist durchaus etwas, das regelmäßig vorkommt, nur:
a) Die Original-Exception wird als cause mitgegeben. Sst verlierst Du Informationen, wo die NPE eigentlich entstanden ist!
b) handelt es sich dann bei der neuen Exception in der Regel um eine Domain spezifische Exception. Das ist bei Dir aber auch nicht der Fall.
(Die NPE ist diesbezüglich auch nicht vorgesehen, daher gibt es keinen Konstruktor, der die Cause entgegen nimmt.)
 
M

Mart

Gast
ich könnte es in meine Heroisch ausformulierte domain exception umändern , falls das eher gemacht wird

die hab ich ja seit längerem
Java:
public class RapidFXException extends Exception
{
    public RapidFXException(String errorMessage)
    {
        super(errorMessage);
    }
}

und es wird ja nicht nur getResource sondern auch toString hergenommen, es ist halt sehr "basis" orientiert ... alle anderen klassen benutzen diese mehtode irgendwie was es halt irgendwie übersichtlicher macht da ich sonst 10000 mal getResource To string drin hab

z.b von einer klasse die von der erbt wo die getResource drin ist.. ist halt sehr aufgeteilt
Java:
    protected final void cssStyleRoot()
    {
        root.getStylesheets().add(findCssStyleSheet());
    }

    private final String findCssStyleSheet()
    {
        return getResource(getClass().getSimpleName() + ".css");
    }

also dass die NPE die eine NPE überarbeitungs würdig ist versteh ich ja aber
wraum das getResource kritisch ist muss mir jemand genauer erklären

in einer anderen klasse hab ichs wieder gebraucht
Java:
    private final File getFile(String fileName)
    {
        URI uri;
        try
        {
            uri = new URI(getResource(fileName));
            return new File(uri);
        } catch (URISyntaxException e)
        {
            e.printStackTrace();
            return null;
        }
    }

... und es kommt noch in vielen mehr vor
 
Zuletzt bearbeitet von einem Moderator:
K

kneitzel

Gast
ich könnte es in meine Heroisch ausformulierte domain exception umändern , falls das eher gemacht wird

die hab ich ja seit längerem
Java:
public class RapidFXException extends Exception
{
    public RapidFXException(String errorMessage)
    {
        super(errorMessage);
    }
}
Dann wäre es wenigstens etwas besser - aber bitte ein Konstruktor mitnehmen, der auch Throwable cause als Parameter hat!

Aber das ändert nichts daran, dass Du eine Methode getRessource hast, die eigentlich nur getRessource aufruft. Wo ist bitte der Mehrwert?
 
M

Mart

Gast
Aber das ändert nichts daran, dass Du eine Methode getRessource hast, die eigentlich nur getRessource aufruft. Wo ist bitte der Mehrwert?
ich muss nicht mehr this.getClass().getResource("xyz").toString() mehr schreiben... das ist mir auf die nerven gegangen :D
im prinzip verkürze ich es um das ToString() und getClass() somit habe ichn ur noch this.getResource("xyz")

der aufruf ist halt oft vorgekommen .. .insgesamt 4 oder 5 mal in meiner API und in dem anderen Projekt auch noch paar mal
somit hab ich halt duplikationen vermieden

es sollte halt das coden vereinfachen ohne zusätzliche funktionalität zu liefern
 
M

Mart

Gast
man kanns wahrscheinlich anzweifeln aber die 2 methoden immer wieder aufzurufen war mir zu nervig lieber dann nur eine
 

mrBrown

Super-Moderator
Mitarbeiter
Was da aus meiner Sicht problematisch ist:

  • NPE zu fangen ist nahezu immer Unsinn, stattdessen einfach explizit selbst auf null prüfen und wenn nötig selbst eine NPE werfen (oder besser was passenderes)
    • Und wenn man die Exception fängt und eine eigene wirft: immer die ursprüngliche Exception mitgeben
  • this.getClass in Verbindung mit getResource und Vererbung kann unerwartete Sachen machen, ist hier aber wahrscheinlich gewollt? Eher würde ich da aber dann die gewünschte Klasse explizit übergeben, damit das offensichtlicher ist
  • toString auf eine URL/URI würde ich an deiner Stelle auch immer so spät wie möglich machen (du brauchst es ja selbst zT dann wieder als URI), das frühe Umwandeln bringt höchstens Probleme mit sich
 
M

Mart

Gast
NPE zu fangen ist nahezu immer Unsinn, stattdessen einfach explizit selbst auf null prüfen und wenn nötig selbst eine NPE werfen (oder besser was passenderes)
gut das mach ich
  • Und wenn man die Exception fängt und eine eigene wirft: immer die ursprüngliche Exception mitgeben
habe ich das nicht mit e.getMessage? , ich bau das sowieso raus aber es ist interessant zu wissen
  • this.getClass in Verbindung mit getResource und Vererbung kann unerwartete Sachen machen, ist hier aber wahrscheinlich gewollt? Eher würde ich da aber dann die gewünschte Klasse explizit übergeben, damit das offensichtlicher ist
es ist tatsächlich so gewollt ... mal zur abwechslung :D
  • toString auf eine URL/URI würde ich an deiner Stelle auch immer so spät wie möglich machen (du brauchst es ja selbst zT dann wieder als URI), das frühe Umwandeln bringt höchstens Probleme mit sich
ursprünglich war es gedacht nur für die Views zu benutzen, es hat sich ergeben dass man es für mehr hernehmen kann und auch guddi Funktioniert

dass ich das getResource von URI -> String -> uri umcaste ist mir noch gar nicht aufgefallen, das muss ich mir mal in dem getFile anschauen
 
M

Mart

Gast
Java:
    public final String getResource(String resourceName)
    {
            return getResourceURI(resourceName).toString();
    }

    public final URL getResourceURI(String resourceName)
    {
        URL url = getClass().getResource(resourceName);
        if (url == null) {
            System.err.println("The Resource::  " + resourceName + "\nwas not found in:: " + this.getClass()
            + " ::\nThis can be caused by not having \"opens PACKAGENAME\" in the module info so it's not accessible\nThe Resource was null::\n");
        }
        return url;
    }
ich habe es jetzt mal versucht umzubauen , da das wichtige eig nur ist wo die Datei Gesucht wurde und nicht gefunden wurde, ob es jetzt in einen NPE ausartet ist eig egal oder ob die EXCEPTION behandelt wird

this.getClass() und resourceName sind wichtig dass man weis wo was nicht gefunden wurde
 
M

Mart

Gast
wenn ich mit absicht jetzt den Fehler herbeizauber dann wird diese Ausgabe ausgegeben passt das denn so oder gibts mehr Verbesserungs Vorschläge? bzw hab ich wieder was unheimlich dämliches gemacht?
Java:
The Resource::  L.properties
was not found in:: class de.github.yfons.rapidfx.examples.LanguageChanging.LanguageManger ::
This can be caused by not having "opens PACKAGENAME" in the module info so it's not accessible
The Resource was null::

Exception in Application start method
java.lang.reflect.InvocationTargetException
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:568)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:465)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:364)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:568)
    at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1071)
Caused by: java.lang.RuntimeException: Exception in Application start method
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196)
    at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.NullPointerException: Cannot invoke "java.net.URL.toURI()" because the return value of "de.github.yfons.rapidfx.premade.language.RLanguageManager.getResourceURI(String)" is null
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.premade.language.RLanguageManager.getFile(RLanguageManager.java:151)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.premade.language.RLanguageManager.setSupportedLanguages(RLanguageManager.java:76)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.premade.language.RLanguageManager.<init>(RLanguageManager.java:37)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.examples.LanguageChanging.LanguageManger.<init>(LanguageManger.java:16)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.examples.LanguageChanging.Launcher.start(Launcher.java:30)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:847)
    at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
    at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
    at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
    at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
    at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
    at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
    ... 1 more
Exception running application de.github.yfons.rapidfx.examples.LanguageChanging.Launcher
 

mrBrown

Super-Moderator
Mitarbeiter
Sinnvoller wäre es, statt der Ausgabe auf System.err eine Exception zu werfen, mit deiner spezifischen Fehlermeldung als Message, und die dann weiter oben irgendwo zu fangen, im Idealfall so weit oben wie möglich
 
M

Mart

Gast
ich kann das schon so umbauen dass es von "ganz oben" abgefangen wird

ungefähr 70% der methoden werfen halt dann die Exception

weil jede "Grund Methode" throws die Exception die von den anderen nicht abgefangen wird

also ist die Frage => sollte ich es dann trotzdem so machen auch wenn ich dann ganz viele throws habe?
 

LimDul

Top Contributor
ich kann das schon so umbauen dass es von "ganz oben" abgefangen wird

ungefähr 70% der methoden werfen halt dann die Exception

weil jede "Grund Methode" throws die Exception die von den anderen nicht abgefangen wird

also ist die Frage => sollte ich es dann trotzdem so machen auch wenn ich dann ganz viele throws habe?
Deswegen verwendet man ein RuntimeException - die muss man nicht deklarieren.
 
M

Mart

Gast
Java:
    private void incompatiblePropertiesErrorMessage(final Field bindToField)
    {
        throw new RapidFXRuntimeException(
                "The Field is not  A EventHandler or A ChangeListener or an Assignable Property"
                +"\n => NAME => "+ bindToField.getName()
                +"\n => CLASS => " + bindToField.getDeclaringClass()
                +"\n => TYPE => " + bindToField.getType()
                +"\n => EXPECTED_TYPE => "+fieldFromProperty.getType()
                +"\n => BASED_ON_FIELD => "+ fieldFromProperty.getName()
                +"\n => BASED_ON_CLASS => "+fieldFromProperty.getDeclaringClass()
                );
    }
hab das ganz verpeilt gehabt dass ich selber runtime exceptions bauen kann
nungut jetzt siehts so aus und ist auch jetzt ne geworfene Exception

das ist ein Beispiel von einer Exception , ich kann halt realtiv genau sagen was nicht passt wenn die Exceptions auftreten


eine komplette exception schaut dann so aus
Java:
Exception in Application start method
java.lang.reflect.InvocationTargetException
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:568)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:465)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:364)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:568)
    at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1071)
Caused by: java.lang.RuntimeException: Exception in Application start method
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196)
    at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: de.github.yfons.rapidfx.rapidFX.core.RapidFXRuntimeException: The Field is not  A EventHandler or A ChangeListener or an Assignable Property
 => NAME => titleTextProperty
 => CLASS => class de.github.yfons.rapidfx.examples.HelloWorld.LoginModel
 => TYPE => class javafx.beans.property.ObjectProperty
 => EXPECTED_TYPE => class javafx.beans.property.StringProperty
 => BASED_ON_FIELD => titleTextProperty
 => BASED_ON_CLASS => class de.github.yfons.rapidfx.examples.HelloWorld.LoginView
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.core.helper.RConnector.incompatiblePropertiesErrorMessage(RConnector.java:76)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.core.helper.RConnector.connectOnPropertyInterface(RConnector.java:69)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.core.helper.RConnector.connectProperties(RConnector.java:53)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.core.helper.FieldHandler.launchConnector(FieldHandler.java:58)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.core.helper.FieldHandler.bindProperties(FieldHandler.java:50)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.core.RapidFX.connect(RapidFX.java:130)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.core.RapidFX.rapidGenerate(RapidFX.java:59)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.simple.RapidSimpleController.rapidFXgenerateMe(RapidSimpleController.java:43)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.examples.HelloWorld.Login.<init>(Login.java:33)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.core.helper.RCreator.create(RCreator.java:11)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.rapidFX.core.RapidFX.create(RapidFX.java:36)
    at de.github.yfons.rapidfx/de.github.yfons.rapidfx.examples.HelloWorld.Launcher.start(Launcher.java:39)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:847)
    at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
    at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
    at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
    at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
    at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
    at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
    ... 1 more
Exception running application de.github.yfons.rapidfx.examples.HelloWorld.Launcher
 

Oneixee5

Top Contributor
Da die Diskussion gar nicht abreist, will ich auch noch mal meine 2 Cent dazutun.
getClass().getResource(resourceName)
Eine Resource ist Bestandteil des Moduls, also auch Archivs wie JAR, WAR, EAR, ZIP oder was auch immer. Die extrahierte Form der Anwendung in der IDE ist ja auf jeden Fall die Ausnahme. Warum sollte man eigentlich überhaupt prüfen ob eine Resource vorhanden ist? Das ist überflüssig, eine Resource verschwindet ja nicht einfach, wie z.B.: ein eingesteckter USB-Stick. Sie ist einfach da und zwar immer. In diesem Fall sogar im selben Package wie die aufrufende Klasse. Sollte eine Resource nicht verfügbar sein, dann gibt es 2 Möglichkeiten. Entweder ich befinde mich in der IDE und arbeite gerade daran ober mein Archiv ist korrupt. Ein korruptes Archiv könnte entstehen wenn mein Build-System nicht funktioniert oder wenn jemand das Archiv manipuliert hat. Dinge wie defekter Download, Virenscanner, etc. schließe ich da mal ein. Der erste Fall wird hoffentlich durch Test erkannt. Den zweiten Fall kann ich nur behandeln, indem ich das gesamte Archiv prüfe (z.B.: Prüfsumme in einem Installationsprogramm), nicht nur eine Ressource.
In beiden Fällen besteht aber kein Grund warum die Anwendung das Problem behandeln soll. Die Anwendung kann das auch gar nicht behandeln, wozu auch. Jemand hat das JAR manipuliert und die Anwendung gibt noch Tipps, wie man das besser machen kann. Das ist doch absurd.
Wollte die Anwendung in diesem Fall überhaupt etwas tun, dann würde diese einen Error werfen und keine Exception. Damit wäre das Programm zu Ende.
getClass().getResource(resourceName).toString();
Im ersten Fall (oben) habe ich ein URL-Objekt. Warum sollte man daraus einen String machen? Mir fällt dazu kein Grund ein. Um die Resource zu laden muss ich aus dem String wieder eine URL-Objekt machen ... Möglicherweise gibt es ja einen Grund, welchen ich nicht sehe.

Ich habe mir zu dem Thema auch noch mal die Doku und Tutorials von Oracle dazu angesehen. Nicht mal Oracle selbst thematisiert das Problem einer fehlenden Resource, weil es einfach keins ist.

Hier noch ein kurzer Auszug der Oracle Webseite:
If the resource is in a JAR file:
  • getResource() invocations will succeed for all files, regardless of whether the invocation is done from within a system or a non-system class.
  • getResourceAsStream() invocations will succeed for non .class resources, and so will for java.net.URL.getContent() on corresponding URLs.
Noch mal auf deutsch - Wenn sich die Ressource in einer JAR-Datei befindet:
  • getResource()-Aufrufe werden für alle Dateien erfolgreich sein, unabhängig davon, ob der Aufruf innerhalb einer System- oder einer Nicht-System-Klasse erfolgt.
  • getResourceAsStream()-Aufrufe sind für Nicht-.class-Ressourcen erfolgreich, ebenso wie java.net.URL.getContent() für entsprechende URLs.
 

mrBrown

Super-Moderator
Mitarbeiter
In diesem Fall sind allerdings aufrufende Klasse und die Resource wahrscheinlich in unterschiedlichen Modulen, da die Klasse hier ja Teil eines Frameworks ist. Da eine RuntimeException schmeißen, wenn der Nutzer des Frameworks einen Fehler macht, finde ich genau
 

Oneixee5

Top Contributor
In diesem Fall sind allerdings aufrufende Klasse und die Resource wahrscheinlich in unterschiedlichen Modulen, da die Klasse hier ja Teil eines Frameworks ist. Da eine RuntimeException schmeißen, wenn der Nutzer des Frameworks einen Fehler macht, finde ich genau
Das geht gar nicht so. Warum ignorieren was Oracle dazu schreibt?
 
M

Mart

Gast
Das geht gar nicht so. Warum ignorieren was Oracle dazu schreibt?
also in meinem Framework ist die Methode drin die eine Abstrakte Klasse ist, die implementierung ist aber dann in deinem Projekt
das getResource wird ja dann im this context aufgerufen dh die Resource wird da gescuht wo die konkrete implementierung drin ist

ich habe insgesamt so 5 exceptions die so auftreten können und jede einzelne exception wird NIEMALS auftreten wenn das fertige Produkt ein User nutzt ( und die jar nicht mit absicht zerschießt ) auftreten ich habe da halt ein paar

die Exception tritt auf wenn man in der einen Klasse als Attribut eiene StringProperty festgelegt hat und in der anderen eine ObjectProperty
weil man sie dann nicht binden kann

oder wenn man versucht StringPRperty mit Integer zu binden, ich denke nicht dass diese Exception auftreten wird wenn das programm fertig wird
hat denke ich nur sinn sodass man einfacher das framework nutzen kann
Java:
    private void incompatiblePropertiesErrorMessage(final Field bindToField)
    {
        throw new RapidFXRuntimeException(
                "\nThe Field is not  A EventHandler or A ChangeListener or an Assignable Property"
                +"\n\t=> NAME => "+ bindToField.getName()
                +"\n\t=> CLASS => " + bindToField.getDeclaringClass()
                +"\n\t=> TYPE => " + bindToField.getType()
                +"\n\t=> EXPECTED_TYPE => "+fieldFromProperty.getType()
                +"\n\t=> BASED_ON_FIELD => "+ fieldFromProperty.getName()
                +"\n\t=> BASED_ON_CLASS => "+fieldFromProperty.getDeclaringClass()
                );
    }
diese Exception könnte während der Laufzeit auftreten aber das ist wie du gesagt hast mit den Files , wenn die mal da sind wirds nicht passieren dass es während der Nutzung auftritt vom ganzen programm
Java:
    private void isEmptyFieldErrorMessage(final Field bindToField)
    {
        throw new RapidFXRuntimeException(
                "\nThe Value of the Field which should be a Property/EventHandler/ChangeListener is null, can't bind to null"
                        + "\n\t=> NAME => " + bindToField.getName()
                        + "\n\t=> CLASS => " + bindToField.getDeclaringClass()
                        + "\n\t=> TYPE => " + bindToField.getType()+"\n");
    }


... das zieht sich halt durch alle meiner Exceptions so durch, es ist wurscht ob man sie abfängt oder nicht
EDIT:
die exception hab ich noch wo man attribute mit untershciedlichen namen binden will dsa wird eher untwahrscheinlich in dem release auftreten
Java:
            throw new RapidFXRuntimeException(
                    "\nThe Field was not found\nThis can be caused when the Module-Info doesn't \"open PACKAGENAME\" where the Class is Part of"
                            + "\n\t=> NAME => " + fieldName
                            + "\n\t=> CLASS => " + bindTo.getClass()
                            + "\n\t=> EXPECTED TYPE => " + field.getType() + "\n");
 
Zuletzt bearbeitet von einem Moderator:

Oneixee5

Top Contributor
Diesen Ansatz finde ich auch komisch. Wenn ich eine abstrakte Klasse habe, warum dieses final getResource? Noch dazu wird gar keine Ressource geladen, sondern nur eine URL als String zurückgegeben. Möglicherweise will jemand die Ressourcen gar nicht so laden. Man könnte sie auch aus einer DB laden wollen oder ganz anders.
Was ich oben beschrieben habe hat nichts mit Exceptions zu tun, welche sonst noch auftreten können.
 
M

Mart

Gast
Also das final wurde genommen weil wenn man nicht die Simple klassen verwenden will dann sollte man es bleiben lassen und selber schreiben

dsa ist der Aufbau der Klassen, das "framework" funktioniert mit allen interfaces alleine dh die Simple klassen ( also die abstrakten ) sind nicht notwendig oder sind gezwungen herzunehmen... du kannst dir das simple natürlich auch selber shcreiben solange es von interfaces abhängt ( das ist das Interface RapidFXComponent ) das hat nur eine default methode und sonst nichts dh da wirst du zu gar nix gezwungen, es war von anfang an so gedacht dass ich wenig vorgaben gebe wie was ausschauen sollte und insgesamt braucht man 2 interfaces um alles mit dem Framework machen zu können , das ist RapidFXComponent und RapidFXView ( und diese muss nicht mal richtig implementiert sein)

deswegen habe ich inden simpel klassen viele sachen final gemacht da implementierungen die Funktionialität erweitern sollten und nicht einschränken du kannst ja trotzdem immer noch deine methode schreiben musst sie halt nur anders nenenn :D
aufbau.png
das obige war so gemeint => ja ich verstehe dass die Exception mit getResource nicht im Live system auftreten wird aber es wird dem Benutzer des frameworks helfen weiterzukommen
und das trifft auf alle Exceptions die ich besitze zu
Java:
public interface RapidFXComponent
{
    default void RapidFXSetUPMe()
    {
            RapidFX.setUp(this);
    }
}

diese vorgabe sollte überschaubar sein :D

und ich weis man sollte default nicht sooooooo wirklich hernehmen
da fand ich es so "nützlicher" als ein leeres interface da zu lassen da es ja doch um funktionialität erweitert .. wenn auch im geringen masen
 

Neue Themen


Oben