LookAndFeel Exceptions bei UIManager.setLookAndFeel

[einekurzefrage]

Hallo zusammen!

Ich habe eine Frage zur Methode

UIManager.setLookAndFeel(String)

Diese Methode wirft ja theoretisch allerhand Exceptions. Mir ist nun nicht ganz klar, in welchen Fällen diese Exceptions jeweils auftreten.

Ich benutze ein 3rd Party Look & Feel, welches in mein Projekt eingebunden ist. Die isSupported()-Methode ist von diesem LAF einfach mit "return true" implementiert, d.h. die UnsupportedLookAndFeelException kann wohl schon mal sicher nicht auftreten.

Aber was ist mit den anderen? Wenn das Laden des Look and Feel bei mir beim Testen funktioniert, kann ich dann daraus schließen dass es auch auf allen Systemen funktioniert? Oder kann es sein dass dieser ClassLoader zum Beispiel manchmal die Datei einfach nicht laden kann, oder es irgendein Problem mit dem SecurityManager gibt (der ist da scheinbar auch im Spiel, ich hab mir den Source mal angesehen von der Methode), z.B. Firewall oder sowas?

Ich würde das gerne wissen weil ich gerade nicht weiß wie ich reagieren soll (was ich in das catch schreiben soll), und ob ich überhaupt reagieren muss. Denn wenn die Methode nur rein syntaktisch Exceptions wirft, aber in meinem konkreten Fall zur Laufzeit sicher keine aufrteten kann, dann muss ich mir nicht die Arbeit machen da irgendwie zu reagierne (z.B. eine fehlermeldung anzeigen).

Ich würde mich über Antworten sehr freuen, thx

 

[jgh]

also wenn -auch nur rein theoretisch- Exceptions geschmissen werden können, dann solltest du diese auch behandeln (imho)...und ein Logger, oder eine JOptionPane mit dem Stacktrace ist ja nicht wirklich viel "Arbeit"...zumal du das L&F ja nur einmal am Anfang setzen solltest.

 

[einekurzefrage]

also wenn -auch nur rein theoretisch- Exceptions geschmissen werden können

Ja, aber das "rein theoretisch" interessiert mich ja auch nur für mein konkretes Programm. Ich benutze das nicht innerhalb eines Frameworks, sondern in einer konkreten Anwendung. Sun schmeißt doch eine Exception weil sie nicht wissen wie das benutzt wird, und es sein könnte dass die Klasse mit dem gegebenen Namen nicht gefunden wird etc. Aber wenn ich jetzt einen gültigen Namen übergebe, und das L&F eingebunden ist, und ich starte das Ding und es gibt keinen Fehler - heißt das nicht dass es halt nun mal alles richtig ist? Wenn nämlich in diesem Fall einfach keine Exception auftreten kann, halte es für unnötig, da irgendwie zu reagieren. Das ist doch nur toter Code der meinen Source aufbläht. Folgendes habe ich auch schon oft gesehen:

try{
   Thread.sleep(x);
}
catch(InterruptedException e){}

Wenn man eine einfache Anwendung hat und man weiß dass nirgendwo ein interrupt() aufgerufen wird, warum dann da irgendwas reinschreiben? Der catch-Block an sich ist ja schon lästig genug..

Ich sehe das im Moment so dass er die Datei findet und das laden kann. Ich meine es ist ja auch nicht so dass der ClassLoader zur Laufzeit eventuell irgendwelche Klassen aus meinem Projekt nicht laden kann, oder?

Aber ich bin mir nicht sicher..

 

[einekurzefrage]

Achso entschuldige, ich kann nicht editieren, aber ich wollte noch sagen:

und ein Logger, oder eine JOptionPane mit dem Stacktrace ist ja nicht wirklich viel "Arbeit"

Wenn dann würde ich den Benutzer natürlich schon darauf hinweisen wollen, also mit einem Dialog. Aber die JOptionPane Dialoge vermeide ich, da sie ohne owner starten und im Desktop untergehen können (Siehe Fenster ausblenden Feature von Windows 7), ich finde das doof. Ich würde mir wenn dann ein Frame dafür erzeugen usw, aber das ist dann doch etwas mehr Arbeit als nur ein Einzeler. Und warum sollte ich jetzt Klassen schreiben und da eine große fehlermeldung anzeigen, wenn es einfach nicht passieren kann?

 

[Mujahiddin]

Throws:
ClassNotFoundException - if the LookAndFeel class could not be found
InstantiationException - if a new instance of the class couldn't be created
IllegalAccessException - if the class or initializer isn't accessible
UnsupportedLookAndFeelException - if lnf.isSupportedLookAndFeel() is false
ClassCastException - if className does not identify a class that extends LookAndFeel

ClassNotFoundException - plattformunabhängig
InstantiationException - plattformunabhängig
IllegalAccessException - plattformunabhängig
UnsupportedLookAndFeelException - weißt du ja selbst
ClassCastException - plattformunabhängig.

Wann welche Exception geschmissen wird, steht jeweils daneben...
Bei IllegalAccessException ist es so, dass zu einigen Libraries der Access verhindert wird. Sollte aber in deinem Fall nicht passieren.

Falls dein eigenes LookAndFeel in einer eigenen Klasse ist, dann kannst du einfach eine Instanz dieser Klasse erzeugen... Dann musst du nur UnsupportedLookAndFeelException behandeln, woran liegt hier das Problem?